Battery life estimation

ABSTRACT

Digital transaction apparatus including a Data Assistance Device (DAD), including a user interface that is operable to at least select data, and a DAD transmitter, a Digital Transaction Card (DTC), including a Digital Transaction Processing Unit (DTPU), and a DTC receiver, wherein the DAD and DTC are operable to transfer data from the DAD to the DTC and when subsequently using the DTC to effect a digital transaction, the DTC operates in accordance with the data selected and transferred from the DAD to the DTC, wherein the digital transaction apparatus further includes a remaining battery life estimation system operable to detect an occurrence of at least one electrical event and to measure the duration of the at least one electrical event, each electrical event having an associated power usage amount, and, subsequent to detection of an occurrence of an at least one electrical event, the remaining battery life estimation system calculates the total energy usage using the associated power usage amount in respect of the at least one electrical event and the duration of the at least one electrical event.

FIELD OF THE INVENTION

The present invention relates generally to apparatus and methods foreffecting digital transactions, including both financial andnon-financial transactions. The apparatus and method may be particularlyuseful for transactions involving credit and/or debit cards.

BACKGROUND OF THE INVENTION

Credit cards, debit cards store cards and gift cards are examples ofcards that are used for financial transactions throughout the world.Further, other types of cards such as passes, tags and small booklets(which may be referred to collectively as transaction documents) areused for various financial and non-financial transactions. For example,some jurisdictions require proof of age cards for transactions such aspurchasing alcohol or entering into age restricted venues. Otherexamples of proof of age, or proof of identity, documents include driverlicenses which are sometimes used for authentication in respect oftransactions. In some countries, passports and/or other similaridentification documents are issued in the form of a card, or a smallbooklet, and can be used for transactions where identification isrequired including, travel across borders or establishing a bankaccount.

Many transaction documents have a magnetic stripe, which can be encodedwith information such as a unique identification number, expiry dates orother numerical or alphanumerical information. Other types oftransaction documents include contactless stored value smart cards, forexample, closed loop transport cards, such as Myki in Melbourne,Australia, and the Octopus Card in Hong Kong.

Transaction documents may include a chip, smart chip, or smart card chip(in this specification, such chips or devices and other similar types ofmicrocircuit will be referred to generally as Digital TransactionProcessing Units, or DTPUs). DTPUs typically include one or more of aCentral Processing Unit (CPU), Read Only Memory (ROM), Random AccessMemory (RAM), Electrically Erasable Programmable Read Only Memory(EEPROM), a crypto-coprocessor and an Input/Output (I/O) system. Forexample, credit cards often use an EMV device (where EMV is anabbreviation for Europay, MasterCard, and Visa). The EMV device (orother type of DTPU) contains encrypted data relevant to the type oftransaction(s) for which the document will be used. The EMV device maybe read by a scanner (for example, using contactless, close proximitycommunications according to ISO/IEC 14443 which is referred to as NearField Communication (NFC throughout the specification)), by directcontact with chip connected electrodes, or by other means to obtain datafrom the chip. Such transaction documents enabled for use in digitaltransactions by means of a chip, a magnetic stripe, a chip and magneticstripe, or Radio-Frequency IDentification (RFID) are referred tothroughout this specification as digital transaction documents.

Digital transaction documents are configured to work with variouscomponents in a digital transaction system including terminals. Forexample, credit and debit cards work with EFTPOS (Electronic FundsTransfer at Point Of Sale) terminals for Point Of Sale (POS)transactions, and ATM (Automatic Teller Machine) terminals. Otherdigital transaction documents are configured to work with other types ofterminals. Such terminals may be operably connected to financialinstitutions or other third party organizations to enable digitaltransactions to occur by authorizing the transaction or performingassociated processing to enable the transaction.

In another example, identification cards, such as a proof of age cards,are implemented with a chip (or DTPU) containing some, or all, of theinformation of the card owner, along with verification information toconfirm the authenticity of the card. Identification cards may be usedin a digital transaction, whereby it is inserted into, swiped, or waivednear, a terminal to confirm the age of the person holding the card.Other non-financial transactions can be implemented in a similar manner.

Terminals used for transactions with digital transaction documents arereferred to throughout this specification as digital transaction systemdevices. For “Card-Present” transactions, the digital transaction systemdevices may include, for example, POS/EFTPOS terminals, ATMs, andnetwork connected or stand-alone readers for reading other types ofnon-financial transaction documents. The digital transaction devices mayalso be suitable for “Card-Not-Present” transactions, for example,online transactions, Mail Order/Telephone Order (MOTO) transactions, andmay include Internet connected personal computers, smartphones, andtablets. Further, digital transaction system devices include telephonesused to communicate with an operator who uses, for example, a networkconnected terminal to enter transaction document data.

Digital transaction documents have a unique IDentification (unique ID),typically having a number, an alphanumeric ID, or a unique name. Theunique ID may be located on, or in, the digital transaction document,for example, printed or embossed on the document. The unique ID is alsotypically recorded on a database, controlled, for example, by the issuerof the digital transaction document, and accompanied by otherinformation, such as name, address, age, and/or financial informationrelevant to the user/owner of the digital transaction document. Where adigital transaction document has a chip, an EMV device or other type ofDTPU, the unique ID is typically stored on the chip, EMV device or DTPU,respectively.

Credit cards are typically embossed or printed with a Personal/PrimaryAccount Number (PAN) to uniquely identify the account card holder. Astandardized PAN has four fields, namely, a system number, abank/product number, a user account number, and a check digit. This typeof PAN typically has 16 digits, but may have between 13 and 19 digits(for example, an American Express PAN has 17 digits). The first digit isthe card issuer type (for example, Visa, MasterCard or AmericanExpress), and the next 5 to 7 digits is generally referred to as a BankIdentification Number (BIN) and represents the card network, the bankand the product for this bank. The last digit is reserved for a checksumof the previous digits of the PAN. An expiration date is associated withthe PAN and generally includes a month and year code having four digits,but with limited range. The card holder's PAN, name or business, and thecard's expiry date typically appear embossed or printed on the face of acard. Previously, some types of credit card had a magnetic stripeencoding some or all of the card information.

More recently, financial transaction cards have carried a CardVerification Value (CVV) or Card Verification Code (CVC) on the magneticstripe to make it more difficult to replicate a card for fraudulentpurposes. The CVC is usually a unique cryptogram, created based on thecard data, for example, including the card PAN and expiry date, and abank's (or a personalization bureau's) master key, and printed on thecard after personalization data is entered on the card. As aconsequence, a person seeking to use a card for fraudulent purposesrequires possession of the card for a sufficient period of time to makea copy of the magnetic stripe in order to duplicate the card, or to readthe card and manually record the card number, expiry date, and otherdetails printed on the card.

The same principle was subsequently adopted for a second CVC, sometimescalled Card Verification Value 2 (CVV2), which is commonly printed inthe signature panel on the back of the card. The CVV2 is used primarilyto help secure e-Commerce and MOTO transactions. This is a second uniquecryptogram created from card data and the bank's master key (althoughthis is a different cryptogram as compared with the magnetic stripeCVC). The CVV2 is not present on the magnetic stripe.

Some credit cards also have an associated Personal Identification Number(PIN) code, which is primarily used for “Card-Present” transactions. ThePIN must generally be kept confidential, and must be entered on secureand certified terminals to make sure that no-one can gain access to thePIN. Further, in modern credit cards, the PIN can be stored on the chip(for example, an EMV device) in an encrypted form within a cryptogramblock.

There are two main classifications of transactions for which creditcards are used including: “Card-Not-Present” transactions, when usingthe Internet or MOTO; and “Card-Present” transactions, such as used withPOS/EFTPOS and ATM terminals. Card-Present transactions involve EMVdevice readers (including physical contact readers using electrode pinson a card and contactless reading using, for example, Near FieldCommunications (NFC)) and/or magnetic stripe readers. These transactionsgenerally use the full 13 to 19 digit PAN and the 4-digit expirationdate. Card-Not-Present transactions generally require the user to readout to an operator, or enter into a computer, the PAN and expirationdate digits. In some instances, the CVC/CVV2 number is also required.

Other types of digital transaction documents may use various forms ofsecurity, such as PINs, passwords, and the like. However, some othertypes of digital transaction documents do not use such externalsecurity, and rely only upon the authenticity of the document itself,for example, using holograms and other security devices that aredifficult to copy. Further, some types of non-credit card digitaltransaction documents may use chips for security, including chipssimilar to EMV devices.

Cards (or other digital transaction documents) may have data stolen, forexample, using a Radio Frequency (RF) signal to power the card's EMVinternal microprocessor and related transmitter. Generally, the carddata, such as the PAN, expiration date and cardholder's name aretransferred to a wireless terminal. The terminal can be a portable orstationary wireless terminal, and once near a card, uses the RF signalto energize the card to firstly, extract the card data and copy some toa memory storage device, or to online storage, such as, the cloud, andsecondly, use a portable terminal in close proximity to the card toextract monies as a contactless payment (for example, a PayWave and/ortap payment, such transactions being referred to by traders astap-and-pay or tap-and-go), in accordance with a level of transactionthat does not require any authorization. Subsequently, stolen card datacan be uploaded to a duplicate “fake card” or used in onlinetransactions to make fraudulent purchases. Yet another method used tosteal card data for fraudulent use involves hacking into computerdatabases that store card data. This data is then used for transactions,and a card owner may only become aware of this when they see a statementdetailing the transactions made with their card, or card data.

Other ways card data is stolen include phishing scams where the cardholder is tricked into entering a security code along with other carddetails via a fraudulent website. Phishing therefore reduces theeffectiveness of security codes as an anti-fraud means. However,merchants who do not use security codes are typically subjected tohigher card processing costs for transactions, and fraudulenttransactions without security codes are more likely to be resolved infavor of the cardholder, which increases costs for merchants. Yet otherways that security of transactions may be compromised is by skimming andman-in-the-middle attacks.

With the emergence of e-Commerce, an increasing number of transactionsare Card-Not-Present type transactions. However, this type oftransaction is subject to an increasing number of attacks fromfraudsters including attacks that have resulted in increasedverification that has caused a “failure positive” result where the cardholder is legitimate but the transaction is rejected.

Several solutions have been developed to address this growing fraud,including use of virtual account numbers, authentication of cardholdersseparately from the transaction, and use of a hardware token toauthenticate the user. Another proposed solution comprises aninstitution, such as a bank sending a code to the user, typically by SMSto the user's smartphone, which can then be used to authenticate aCard-Not-Present transaction. This arrangement is generally referred toas an Out-Of-Band (OOB) message which unfortunately has been recentlyhacked. In any event, many of these solutions require expensiveinfrastructure changes, which merchants prefer to avoid and may onlyprovide protection for a limited time until the arrangement is hacked.

With the increasing number of Card-Not-Present transactions, a suggestedmeans of conducting such transactions is the electronic wallet(e-wallet), also known as a digital wallet. An e-wallet provides userswith a means to pay for purchases from enabled on-line merchants. Uponregistration, a user can store their card, billing and shippinginformation on a site hosted by a suitable document, such as a bank, andcan access that information to pay for goods or services. However,e-wallets on an NFC enabled device, such as a smartphone, do not operatein a large percentage of Card-Present transactions, for example,POS/EFTPOS or ATM transactions since these network transaction devicesgenerally do not support contactless payments and amongst the presentlyavailable contactless payment arrangements, different back end processesand merchant agreements are involved. As a result, the establishment anduse of e-wallets has experienced limited commercial success and whilstthey remain available to consumers, only approximately 10% of consumershave elected to install an e-wallet although the take-up rate byconsumers is now starting to drop.

A user may prefer to have, and to carry around with them, many of theiravailable credit cards, debit cards, store cards, government agencycards and loyalty cards since they prefer to physically hold and controlthe possession of those cards. Further, a user may require an identitycard, driver's license, age verification card or passport. Carryingaround a large number of individual digital transaction documents can bevery inconvenient. Moreover, the person, having so many physicaltransaction documents, may become confused regarding the location of aparticular digital transaction document, for example, a particularcredit card, among all the other digital transaction documents.

An alternative solution to e-wallets that addresses the problem of userscarrying a large number of credit or debit cards has been developed,wherein a credit card sized device has a keyboard (or touch pad arrangedas a simplified keyboard) and a small limited function Graphical UserInterface (GUI), which are used to select one card amongst a number ofcards stored on the device, and to enter data for various transactions.However, the keyboards are of limited functionality due to their limitednumber of keys in the relatively small space available on the card(being the area of an average credit card). The keyboards are alsoconsidered difficult to use because of their small size, and as a resulta large number of keystrokes may be required to effect any particularfunction. Further, the keyboard on a credit card is not a solution forother types of digital transaction document such as those documents usedfor proof of identity or proof of age. Other attempted solutions includeproducts, such as Plastc, Coin, Final, and Wocket. However, the Plastcsolution has some operational limitations, and the Wocket solutionrequires a specific Wocket device. None of these solutions has gainedwide commercial acceptance. Moreover, it has been found that cardsincluding a keyboard have an unacceptably high failure rate when givento customers in view of the repeated, perhaps daily, usage. It issuggested that the high failure rate may be, at least in part, due tothe complications of having the keyboard on a card, which has limitedspace for such a complex electronic device.

Another problem with attempting to accommodate multiple credit cards,debit cards or other digital transaction documents on a single card arethe limitations caused by the use of proprietary or standardized chips.Such chips or DTPUs are configured to securely store information for onedigital transaction document only. For example, a credit card chip, suchas an EMVCo standard chip, securely holds information typicallyincluding the credit card PAN, the expiry date, a security code (such asthe CCV2 number), and a PIN. Transaction devices, such as POS/EFTPOSterminals, securely communicate with the DTPU to obtain some, or all, ofthe information from the DTPU for a transaction to be authorized andverified. Many DTPUs are also configured to resist attempts to write tothe DTPUs secure record memory (which may also be referred to as asecure element, or part of a secure element), as many such attempts aremade by those seeking to use the card fraudulently. It will beunderstood that a secure element may comprise secure memory and anexecution environment, and is a dynamic environment in which applicationcode and application data can be securely stored and administered.Further, it will be understood that, in a secure element, secureexecution of the application can occur. A secure element may be locatedin a highly secure crypto chip (otherwise known as a smart card chip).The security of the DTPU may also prevent legitimately introducing oneor more new digital transaction documents (including PANs, tokens expirydates, PINs and other data attributes of those documents) into thesecure record memory (secure element) of the DTPU so that the DTPUcannot take on another document's personality (a term which is usedherein to describe a digital transaction document (or logical digitaltransaction document) and its attributes).

Accordingly, it has been difficult to instigate use of single physicalcards having multiple personalities (multiple credit and/or debit cardsexpressed or expressible on a single physical card), given the change ininfrastructure required, including modified DTPUs (such as the EMVCodevice), modified digital transaction devices (for example, modifiedPOS/EFTPOS terminals), along with any other modification required inother parts of the credit/debit card payment infrastructure. Apart fromthe technical problems, Card Association Scheme providers such as Visaand MasterCard have various additional requirements including thepresence of a hologram and logo of the Card Association Scheme on thephysical card.

In this regard, it is desirable to provide a single EMV (or EMV typedevice), or other type of DTPU, on a Digital Transaction Card (DTC), forexample, a credit card sized card, which is able to selectively assumethe personality of a number of different digital transaction documents(or logical digital transaction documents). For example, a user may seekto use MasterCard account for one transaction, but to a use Visa accountfor a different transaction. Alternatively, a user may seek to use theDTC as a credit card, but to subsequently use it as an age identitycard.

However, to-date, there has not been a sufficiently effective,efficient, and/or secure means and/or method for adapting a DTPU (suchas an EMVCo specified device) to embody different personalities ascompared with the personality of the DTPU that was initially installed.

Another problem with present digital transaction documents is theability to obtain data from a credit card or other transaction document.Although devices such as EMV devices have been introduced in an attemptto limit data theft, such arrangements have not proved to be entirelysuccessful in preventing this type of crime. Increasing credit cardfraud may incur cost for a bank, a merchant, a user, or all threeparties. Further, identity theft is an increasing concern for userssince a stolen identity can be used to commit fraudulent financialtransactions, and other types of crime.

For some digital transaction documents, such as credit cards, tokens aresometimes used to enhance security for transactions. For credit cards,tokens are typically numbers that are the same length as the creditcard's PAN, and are substituted for the PAN in a transaction. The tokenshould not be feasibly decryptable to obtain the original PAN by aperson seeking to use the credit card fraudulently, and so that personis unable to mimic the credit card, and unable to use the credit cardsPAN and a card holder's other personal details for on-line transactions.Accordingly, if using a credit card in a high risk, low securityenvironment, tokens are a means of protecting sensitive data. Thesecurity of the token is based primarily on the infeasibility ofdetermining the original PAN (or other data) whilst knowing only thesurrogate token value. Tokenization may be used instead of, or inconjunction with, other encryption techniques in transactions withdigital transaction documents.

A token (or digital token) may be generated by a third party, such as acredit card issuer, a financial institution, or a security provider forthe credit card. Tokens are also used for securing other non-financialtransactions, such as those involving drivers' licenses. The token maybe generated as a cryptogram using inputs from a selection of, forexample, the credit card's PAN (or some other unique ID of a digitaltransaction document), and/or the card's expiry date. The token for atransaction may be selected from a number of tokens in a pool based onthe ID of the merchant or the terminal where the transaction isoccurring, the date of the transaction, the time of the transaction, orvarious other criteria. De-tokenization to retrieve the original PANtypically occurs during the processing of a transaction, and is usuallyperformed by the credit card issuer, financial institution, or securityprovider who issued the token.

Usually, tokens are generated during the process of creating and issuinga credit card to its owner/user. Each card may have one or moreassociated tokens. Where a card has multiple tokens, each token can beselectively used for different transactions or different transactiontypes.

Tokens have a number of problems, including not being selectable by theuser to allow the user control over security and how tokens are used.For example, a user may seek to be able to select tokens for certaintransactions or transaction types. Another problem is that the sametoken may need to be used for a number of different transactions, thuslimiting the security afforded by the token. This is especially the casefor a digital transaction document such as a credit card. Even if adigital transaction document has a number of associated tokens, thosetokens will need to be reused or reissued after a number oftransactions. It is difficult to issue new tokens, for example, to acredit card, since the infrastructure for issuing new tokens has beendeveloped to issue those new tokens at a time of creation and issuanceof a new credit card.

One way to prevent fraudulent use of a stolen or compromised credit cardor other types of transaction document is to simply cancel the document,including cancelation of that document's unique identifier (for example,cancelling the account number of a credit card), and issue a newdocument with a new expiration date. Providers of the document may havea mechanism to invalidate old documents (for example, invalidating oldaccount numbers), and to issue new numbers to existing users. However,it can sometimes take a substantial amount of time to deliver a newdocument (for example, delivering a credit card through the mail), andthe delay greatly inconveniences the user. In the instance of a creditcard, the issuance of a new card causes a temporary cessation of theuser's ability to maintain payments by auto debit from credit accounts.

Further, document owners generally prefer instant or near instant (“realtime”) feedback of information regarding use of their card for financialtransactions or other types of transaction, such as use of a card orother such documents for identification, traveling and other purposes.Card owners may also prefer real time feedback regarding accountbalances and other information related to their card, or other digitaltransaction documents. Further, owners of cards and other digitaltransaction documents may prefer the ability to block usage of adocument in real time, or with minimal delay. This may be useful if theowner becomes aware of, or suspects, fraudulent transaction(s) with theuse of one or more of their digital transaction document(s).

Additionally, many electrical devices use a battery, and moreparticularly, a rechargeable battery as a power source. Presently, it isdifficult to know when a battery will fail, or begin to fail wherein thedevice will cease to operate with sufficient reliability. Nonrechargeable batteries have a limited life before becoming discharged.Rechargeable batteries are able to be recharged at, or toward, the endof a recharge cycle when the battery charge is low. However, it can bedifficult to determine when the recharging is required.

Further, rechargeable batteries have a limited number of rechargingcycles before the battery fails. Typically, a battery (rechargeable ornon-rechargeable) will have a flat voltage supply for most of its life.As the battery life ends, the voltage may drop rapidly without warning.

It is difficult to predict when a battery or rechargeable battery willfail or begin to fail. Measuring instantaneous current and/or voltage ofa battery is typically used to provide an indication of the state of thebattery, and is used to estimate when the battery is coming to the endof its life, or its recharge cycle. However, current/voltage indicatorsare not accurate and do not provide sufficient information to properlydetermine the end-of-life of a non-rechargeable battery or the rechargerequirement for a rechargeable battery. More particularly, instantaneouscurrent/voltage measurements do not provide an accurate estimate of theend-of-life for a rechargeable battery.

In small devices, it is difficult to provide an indication of thebattery condition, since the size of the device may prevent the fittingof a battery charge indicator. For example, some credit cards, debitcards and similar devices may be fitted with a battery, but cannotprovide a direct indication of the battery's condition. In such cards,the battery is sealed inside the device and may fail without warning.Sometimes, batteries in service that are just within acceptable limitswill fail early creating problems for in-field credit card usage,wherein batteries fail with little or no user notification. This resultsin problems for users that are unable to use their credit card.

The failure of a battery depends upon a number of factors, including:

-   -   short battery life caused by faulty manufacturing, or large        manufacturing tolerances;    -   excess time in a cold environment/extreme cold;    -   excessive shelf life before being placed into service (including        issues relating to self-discharge rate);    -   connected components exceeding manufacturer's specified current        load; and/or    -   excess usage draining battery well before average life span.

It is an object of the present invention to overcome, or at leastameliorate, at least one of the above-mentioned problems in the priorart, and/or provide at least a useful alternative to prior art devices,systems and/or methods,

SUMMARY OF THE INVENTION

In one aspect, the present invention provides a remaining battery lifeestimation apparatus operable to detect an occurrence of at least oneelectrical event and to measure the duration of the at least oneelectrical event, each electrical event having an associated power usageamount, and, subsequent to detection of an occurrence of an at least oneelectrical event, the remaining battery life estimation apparatuscalculates the total energy usage using the associated power usageamount in respect of the at least one electrical event and the durationof the at least one electrical event.

In another aspect, the present invention provides a remaining batterylife estimation apparatus operable to detect an occurrence of at leastone electrical event, each electrical event having an associated energyusage amount, and, subsequent to detection of an occurrence of an atleast one electrical event, the remaining battery life estimationapparatus calculates the total energy usage using the associated energyusage amount in respect of the at least one electrical event.

In another aspect, the present invention provides a digital transactionapparatus including a Data Assistance Device (DAD) including, a userinterface that is operable to at least select data, and a DADtransmitter, a Digital Transaction Card (DTC), including a DigitalTransaction Processing Unit (DTPU), and a DTC receiver, wherein the DADand DTC are operable to transfer data from the DAD to the DTC and whensubsequently using the DTC to effect a digital transaction, the DTCoperates in accordance with the data selected and transferred from theDAD to the DTC, wherein the digital transaction apparatus furtherincludes a remaining battery life estimation system operable to detectan occurrence of at least one electrical event and to measure theduration of the at least one electrical event, each electrical eventhaving an associated power usage amount, and, subsequent to detection ofan occurrence of an at least one electrical event, the remaining batterylife estimation system calculates the total energy usage using theassociated power usage amount in respect of the at least one electricalevent and the duration of the at least one electrical event.

In another aspect, the present invention provides a digital transactionapparatus including a Data Assistance Device (DAD) including, a userinterface that is operable to at least select data, and a DADtransmitter, a Digital Transaction Card (DTC), including a DigitalTransaction Processing Unit (DTPU), and a DTC receiver, wherein the DADand DTC are operable to transfer data from the DAD to the DTC and whensubsequently using the DTC to effect a digital transaction, the DTCoperates in accordance with the data selected and transferred from theDAD to the DTC, wherein the digital transaction apparatus furtherincludes a remaining battery life estimation system operable to detectan occurrence of at least one electrical event, each electrical eventhaving an associated energy usage amount, and, subsequent to detectionof an occurrence of an at least one electrical event, the remainingbattery life estimation system calculates the total energy usage usingthe associated energy usage amount in respect of the at least oneelectrical event.

In another aspect, the present invention provides a Data AssistanceDevice (DAD) including a user interface that is operable to at leastselect data and a DAD transmitter that is operable to transfer data fromthe DAD to a receiver associated with a Digital Transaction Card (DTC),wherein the data that is selected and transferred to the DTC causes theDTC to operate in accordance with the selected data when the DTC issubsequently used to effect a digital transaction, wherein the DADand/or the DTC further includes a remaining battery life estimationsystem operable to detect an occurrence of at least one electrical eventand to measure the duration of the at least one electrical event, eachelectrical event having an associated power usage amount, and,subsequent to detection of an occurrence of an at least one electricalevent, the remaining battery life estimation system calculates the totalenergy usage using the associated power usage amount in respect of theat least one electrical event and the duration of the at least oneelectrical event.

In another aspect, the present invention provides a Data AssistanceDevice (DAD) including a user interface that is operable to at leastselect data and a DAD transmitter that is operable to transfer data fromthe DAD to a receiver associated with a Digital Transaction Card (DTC),wherein the data that is selected and transferred to the DTC causes theDTC to operate in accordance with the selected data when the DTC issubsequently used to effect a digital transaction, wherein the DADand/or the DTC further includes a remaining battery life estimationsystem operable to detect an occurrence of at least one electricalevent, each electrical event having an associated energy usage amount,and, subsequent to detection of an occurrence of an at least oneelectrical event, the remaining battery life estimation systemcalculates the total energy usage using the associated energy usageamount in respect of the at least one electrical event.

In another aspect, the present invention provides a Digital TransactionCard (DTC) including a Digital Transaction Processing Unit (DTPU) and aDTC receiver that is operable to receive user-selected data from atransmitter associated with a Data Assistance Device (DAD), wherein theuser-selected data that is received causes the DTC to operate inaccordance with the user-selected data when the DTC is subsequently usedto effect a digital transaction, wherein the DAD and/or the DTC furtherincludes a remaining battery life estimation system operable to detectan occurrence of at least one electrical event and to measure theduration of the at least one electrical event, each electrical eventhaving an associated power usage amount, and, subsequent to detection ofan occurrence of an at least one electrical event, the remaining batterylife estimation system calculates the total energy usage using theassociated power usage amount in respect of the at least one electricalevent and the duration of the at least one electrical event.

In another aspect, the present invention provides a Digital TransactionCard (DTC) including a Digital Transaction Processing Unit (DTPU) and aDTC receiver that is operable to receive user-selected data from atransmitter associated with a Data Assistance Device (DAD), wherein theuser-selected data that is received causes the DTC to operate inaccordance with the user-selected data when the DTC is subsequently usedto effect a digital transaction, wherein the DAD and/or the DTC furtherincludes a remaining battery life estimation system operable to detectan occurrence of at least one electrical event, each electrical eventhaving an associated energy usage amount, and, subsequent to detectionof an occurrence of an at least one electrical event, the remainingbattery life estimation system calculates the total energy usage usingthe associated energy usage amount in respect of the at least oneelectrical event.

In another aspect, the present invention provides a method forestimating battery life using a remaining battery life estimationapparatus that is operable to detect an occurrence of at least oneelectrical event and to measure a duration of the at least oneelectrical event, each electrical event having an associated power usageamount, and, subsequent to detection of an occurrence of an at least oneelectrical event, the remaining battery life estimation apparatuscalculates the total energy usage using the associated power usageamount in respect of the at least one electrical event and the durationof the at least one electrical event.

In another aspect, the present invention provides a method forestimating battery life using a remaining battery life estimationapparatus that is operable to detect an occurrence of at least oneelectrical event, each electrical event having an associated energyusage amount, and, subsequent to detection of an occurrence of an atleast one electrical event, the remaining battery life estimationapparatus calculates the total energy usage using the associated energyusage amount in respect of the at least one electrical event.

In another aspect, the present invention provides a method forestimating the remaining battery life of a Digital Transaction Card(DTC), the method including selecting data, by a user interface of aData Assistance Device (DAD), transferring the selected data by a DADtransmitter to a receiver associated with the DTC having a DigitalTransaction Processing Unit (DTPU), and effecting, by the DTC, a digitaltransaction wherein the DTC operates in accordance with the dataselected and transferred from the DAD to the DTC, the method furtherincluding implementing a remaining battery life estimation system usingthe DTC and/or the DAD, wherein the remaining battery life estimationsystem is operable to detect an occurrence of at least one electricalevent and to measure a duration of the at least one electrical event,each electrical event having an associated power usage amount, and,subsequent to detection of an occurrence of an at least one electricalevent, calculating with the battery life estimation system the totalenergy usage using the associated power usage amount in respect of theat least one electrical event and the duration of the at least oneelectrical event.

In another aspect, the present invention provides a method forestimating the remaining battery life of a Digital Transaction Card(DTC), the method including selecting data, by a user interface of aData Assistance Device (DAD), transferring the selected data by a DADtransmitter associated with the DAD to a receiver associated with theDTC having a Digital Transaction Processing Unit (DTPU), and effecting,by the DTC, a digital transaction wherein the DTC operates in accordancewith the data selected and transferred from the DAD to the DTC, themethod further including implementing a remaining battery lifeestimation system using the DTC and/or the DAD, wherein the remainingbattery life estimation system is operable to detect an occurrence of atleast one electrical event, each electrical event having an associatedenergy usage amount, and, subsequent to detection of an occurrence of anat least one electrical event, calculating with the battery lifeestimation system the total energy usage using the associated energyusage amount in respect of the at least one electrical event.

In yet another aspect, the present invention provides a method forestimating the remaining battery life of a Digital Transaction Card(DTC), including selecting data, by a user interface of a DataAssistance Device (DAD), and transferring the selected data, by a DADtransmitter to a receiver associated with the DTC having a DigitalProcessing Unit (DTPU), wherein the DTC operates in accordance with theselected and transferred data when the DTC is subsequently used toeffect a digital transaction, the method further including implementinga remaining battery life estimation system using the DTC and/or the DAD,wherein the remaining battery life estimation system is operable todetect an occurrence of at least one electrical event and to measure aduration of the at least one electrical event, each electrical eventhaving an associated power usage amount, and, subsequent to detection ofan occurrence of an at least one electrical event, calculating with thebattery life estimation system the total energy usage using theassociated power usage amount in respect of the at least one electricalevent and the duration of the at least one electrical event.

In yet another aspect, the present invention provides a method forestimating the remaining battery life of a Digital Transaction Card(DTC), including selecting data, by a user interface of a DataAssistance Device (DAD), and transferring the selected data, by a DADtransmitter to a receiver associated with the DTC having a DigitalProcessing Unit (DTPU), wherein the DTC operates in accordance with theselected and transferred data when the DTC is subsequently used toeffect a digital transaction, the method further including implementinga remaining battery life estimation system using the DTC and/or the DAD,wherein the remaining battery life estimation system is operable todetect an occurrence of at least one electrical event, each electricalevent having an associated energy usage amount, and, subsequent todetection of an occurrence of an at least one electrical event,calculating with the battery life estimation system the total energyusage using the associated energy usage amount in respect of the atleast one electrical event and the duration of the at least oneelectrical event.

In a further aspect, the present invention provides a method ofestimating the remaining battery life of a Digital Transaction Card(DTC), the method including operating the DTC, including receiving, froma Data Assistance Device (DAD), data including user-selected data, andeffecting, by the DTC, a digital transaction, wherein the DTC operatesin accordance with the user-selected data, the method further includingimplementing a remaining battery life estimation system using the DTCand/or the DAD, wherein the remaining battery life estimation system isoperable to detect an occurrence of at least one electrical event and tomeasure a duration of the at least one electrical event, each electricalevent having an associated power usage amount, and, subsequent todetection of an occurrence of an at least one electrical event,calculating with the battery life estimation system the total energyusage using the associated power usage amount in respect of the at leastone electrical event and the duration of the at least one electricalevent.

In a further aspect, the present invention provides a method ofestimating the remaining battery life of a Digital Transaction Card(DTC), the method including operating the DTC, including receiving, froma Data Assistance Device (DAD), data including user-selected data, andeffecting, by the DTC, a digital transaction, wherein the DTC operatesin accordance with the user-selected data, the method further includingimplementing a remaining battery life estimation system using the DTCand/or the DAD, wherein the remaining battery life estimation system isoperable to detect an occurrence of at least one electrical event, eachelectrical event having an associated energy usage amount, and,subsequent to detection of an occurrence of an at least one electricalevent, calculating with the battery life estimation system the totalenergy usage using the associated energy usage amount in respect of theat least one electrical event.

In a further aspect, the present invention provides a computer-readablemedium storing one or more instructions that, when executed by one ormore processors associated with a Data Assistance Device (DAD), causethe one or more processors to select data, by a user interface of theDAD, and transfer the selected data, by a DAD transmitter to a receiverassociated with a Digital Transaction Card (DTC) having a DigitalTransaction Processing Unit (DTPU), wherein the DTC operates inaccordance with the selected and transferred data when the DTC issubsequently used to effect a digital transaction, wherein a remainingbattery life estimation system is implemented using the DTC and/or aDigital Assistance Device (DAD) operating with the DTC, and wherein, theone or more instructions further cause the remaining battery lifeestimation system to detect an occurrence of at least one electricalevent and to measure the duration of the at least one electrical event,each electrical event having an associated power usage amount, and,subsequent to detection of an occurrence of an at least one electricalevent, cause the remaining battery life estimation system to calculatethe total energy usage using the associated power usage amount inrespect of the at least one electrical event and the duration of the atleast one electrical event.

In a further aspect, the present invention provides a computer-readablemedium storing one or more instructions that, when executed by one ormore processors associated with a Data Assistance Device (DAD), causethe one or more processors to select data, by a user interface of theDAD, and transfer the selected data, by a DAD transmitter to a receiverassociated with a Digital Transaction Card (DTC) having a DigitalTransaction Processing Unit (DTPU), wherein the DTC operates inaccordance with the selected and transferred data when the DTC issubsequently used to effect a digital transaction, instruction, whereina remaining battery life estimation system is implemented using the DTCand/or a Digital Assistance Device (DAD) operating with the DTC, andwherein, the one or more instructions further cause the remainingbattery life estimation system to detect an occurrence of at least oneelectrical event, each electrical event having an associated energyusage amount, and, subsequent to detection of an occurrence of an atleast one electrical event, cause the remaining battery life estimationapparatus to calculate the total energy usage using the associatedenergy usage amount in respect of the at least one electrical event.

In a further aspect, the present invention provides a computer-readablemedium storing one or more instructions that, when executed by one ormore processors associated with a Digital Transaction Card (DTC), causethe one or more processors to receive user selected data, from a DataAssistance Device (DAD), and subsequently effect a digital transactionwherein the DTC operates in accordance with the user-selected data,wherein a remaining battery life estimation system is implemented usingthe DAD and/or a Data Transaction Card (DTC) operating with the DAD, andwherein, the one or more instructions further cause the remainingbattery life estimation system to detect an occurrence of at least oneelectrical event and to measure the duration of the at least oneelectrical event, each electrical event having an associated power usageamount, and, subsequent to detection of an occurrence of an at least oneelectrical event, cause the remaining battery life estimation system tocalculate the total energy usage using the associated power usage amountin respect of the at least one electrical event and the duration of theat least one electrical event.

In a further aspect, the present invention provides a computer-readablemedium storing one or more instructions that, when executed by one ormore processors associated with a Digital Transaction Card (DTC), causethe one or more processors to receive user selected data, from a DataAssistance Device (DAD), and subsequently effect a digital transactionwherein the DTC operates in accordance with the user-selected data,wherein a remaining battery life estimation system is implemented usingthe DTC and/or a Digital Assistance Device (DAD) operating with the DTC,and wherein, the one or more instructions further cause the remainingbattery life estimation system to detect an occurrence of at least oneelectrical event, each electrical event having an associated energyusage amount, and, subsequent to detection of an occurrence of an atleast one electrical event, cause the remaining battery life estimationsystem to calculate the total energy usage using the associated energyusage amount in respect of the at least one electrical event.

In a further aspect, the present invention provides a method includingreceiving, from an issuing authority, a DTC configured to operate inaccordance with any one or more of the statements above.

In a further aspect, the present invention provides a method includingissuing, by an issuing authority, a DTC configured to operate inaccordance with any one or more of the statements above.

In a further aspect, the present invention provides a method includingreceiving, from an issuing authority, a DTC configured to operate inaccordance with the method of any one or more of the statements above.

In a further aspect, the present invention provides a method includingissuing, by an issuing authority, a DTC configured to operate inaccordance with the method of any one or more of the statements above.

In a further aspect, the present invention provides a method includingissuing, by an issuing authority, operating code, including softwareand/or firmware, to a Data Assistance Device (DAD) and/or a DigitalTransaction Card (DTC) to enable the DAD and/or DTC to operate inaccordance with any one or more of the statements above.

In a further aspect, the present invention provides a method includingissuing, by an issuing authority, operating code, including softwareand/or firmware, to a Data Assistance Device (DAD) and/or a DigitalTransaction Card (DTC) to enable the DAD and/or DTC to operate inaccordance with the method of any one or more of the statements above.

SUMMARY OF EMBODIMENT(S) OF THE INVENTION

In embodiments, the system and/or method includes and/or uses aprocessor for calculating a total energy usage. The processor may alsobe used for other calculations or operations for estimating remainingbattery life in accordance with embodiments of the invention. In someembodiments, the apparatus and/or method is implemented on a DigitalTransaction Card (DTC) operating with a Data Assistance Device (DAD),for example, a smartphone, and the processor may be located on either orboth the DTC and the DAD. In this regard, an apparatus including a DTCand DAD may have processing for calculations and other operationsoccurring on both the DTC and DAD.

In other embodiments, the system and/or method includes and/or uses aclock or other similar timing device for measuring duration of events.In an apparatus using a DTC, the clock or other timing device may belocated on the DTC.

In yet other embodiments, the system and/or method includes and/or usesa digital memory for storing data related to the events, event types,duration and any other related data. In embodiments where the system isimplemented using a DTC and DAD (e.g., smartphone), the digital memorymay be located on the DTC, the DAD (e.g., smartphone) or on bothdevices. Further, the digital memory may be operable to store datarelating to the power usage amounts, or the associated energy usageamounts in respect of the at least one electrical event. In furtheralternative embodiments, the data relating to the associated powerusage, or the associated energy usage amounts in respect of the at leastone electrical event may be stored in other locations, such as on remotedevices in the cloud.

In further embodiments, data relating to the total energy usage may alsobe stored in digital memory.

In embodiments, the apparatus and/or method is also operable tocalculate a grand total energy usage, being energy usage for arechargeable battery across all previous and a present recharge cycle.The nominal grand total energy usage may be compared against an expectedgrand total energy usage to calculate expected remaining rechargeablebattery life (or expected number of remaining recharge cycles).

In the context of the present specification, the term “nominal” is takento mean an expected or average value of power usage but may not be theactual power consumed for a particular electrical event.

In other embodiments, the apparatus and/or method include means or stepsto monitor transactions and other operations of an electronic device(for example a DTC) to detect an occurrence of at least one electricalevent.

In various embodiments, different types of electrical events areassociated with different power usage amounts. Further, a given type ofevent using a number of different components may have differentassociated power or energy usage for each of the components. Forexample, an electrical event may be an operation of a Near FieldCommunication (NFC) device for communication, and the associated nominalpower usage amount may be 5 milliwatts, with a duration of 3 seconds.The energy usage will be 15 milliwatt seconds. In the alternative, theassociated energy usage amount may be 15 milliwatt seconds, being anevent with an expected duration and power usage.

In yet other embodiments, the apparatus and/or method includesassociated power/energy usage amounts as pre-determined amounts.Alternatively, the apparatus/method may allow for determination ofpower/energy usage by measurement of an initial event, then set thenominal power/energy usage amounts, which are used for subsequentevents.

In an example embodiment, the following method may be implemented, forexample, in a system using a DAD (e.g., a smartphone) and DTC (whereinthe battery is located on the DTC):

-   -   Record each resting voltage at the time of installation;    -   Record the battery voltage at the time of going into service;    -   Within the DTC firmware, record the following event types:        authorized and unauthorised use, start time, finish time, length        of time (duration), start voltage, finish voltage, running total        (milliseconds×factory current draw per milliseconds) of each one        of the following (in milliseconds) events for components on the        DTC:        -   authorized/unauthorised use;        -   display;        -   NFC—set parameters;        -   NFC—read;        -   EMV (where EMV is an abbreviation for Europay, MasterCard,            and Visa)—set parameters;        -   DAV—read;        -   DTC processor active;        -   encryption;        -   transaction (with a digital transaction device, such as a            Point Of Sale/Electronic Funds Transfer at Point Of Sale            (POS/EFTPOS) terminal);        -   link time (with the smartphone);        -   data transfer time (between DTC and digital transaction            device or DTC and smartphone); and,        -   other key power drawing functions, such as GPS location            obtained from the smartphone;    -   Install processor script to upload the recorded information when        securely requested (authentication required);    -   install a battery monitoring application on the smartphone;    -   request battery monitoring details from the DTC;    -   display information on the smartphone to alert user of battery        status;    -   ask user if they wish to upload battery performance details to        the issuing financial institution (of the DTC or a        “personality”, for example, a credit card, operating on the        DTC);    -   show on the smartphone screen or DTC display when the battery is        close to the minimum operating voltage (for example, the screen        could show “Battery Voltage OK”; “Battery Voltage Low—Order        Replacement Now”; or “Battery Voltage Low—Recharge Battery        Now”); and,    -   the financial institution can average out the usage patterns and        could identify DTCs that are failing and/or using above the        normal current amounts.

It will be understood by skilled readers that in embodiments of theinvention, a digital transaction apparatus including, and requiringboth, a Data Assistance Device (DAD) and a Digital Transaction Card(DTC) for a digital transaction provides a multi-factor verification(including authorization, authentication, and both authorization andauthentication) for the digital transaction, the factors being that theuser (for example, someone seeking to pay for goods and/or servicesusing a financial digital transaction) requires two items, namely, theDAD and the DTC and also knowledge regarding how to effect a transactionwith the two items. Accordingly, if a person has both a DAD and a DTCwhen seeking to conduct a digital transaction, the likelihood that theperson has obtained both items by fraud, theft, or deception issignificantly reduced. For example, if the DAD is a smartphone, then itis unlikely that a person seeking to conduct a fraudulent transactionwould be able to steal a legitimate DTC and the owner's smartphone whencompared with solely the theft of a legitimate credit card as presentlyused to conduct digital transactions. Further, if a person seeking toconduct a fraudulent transaction managed to steal a legitimate DTC, itwould be very difficult for that person to emulate, or spoof, the DTCowner's smartphone, including any necessary additional hardware andsoftware to operate with the DTC to conduct a digital transaction.

In embodiments, the DAD and DTC are operable to transfer datatherebetween which may further assist to reduce the incidence offraudulent digital transactions. For example, the DAD could be used totransmit a One Time PIN (OTP) to the DTC prior to each and everytransaction, the OTP being requested by a digital transaction systemdevice during a digital transaction and requiring entry of the PIN bythe user to complete the transaction. In any event, it is expected thattransferring data between the DAD and DTC will assist users to manageand monitor their digital transactions.

In embodiments, the present invention provides a method of conductingdigital transactions using a digital transaction apparatus including aplurality of Logical Digital Transaction Document Packets (LDTDPs), eachLDTDP representing a digital transaction document and including one ormore of a unique Identification (unique ID) or a token associated withthe unique ID for performing a digital transaction with at least onedigital transaction device, the digital transaction apparatus furtherincluding, an LDTDP storage memory, a staging memory, a DAD, and a DTC,including a Digital Transaction Processing Unit (DTPU) and a securerecord memory, the method including, operating the DAD to select one ofthe at least one LDTDPs stored in the LDTDP storage memory, copying theselected one LDTDP from LDTDP storage memory to staging memory, andcopying the selected one LDTDP from staging memory to the secure recordmemory thus enabling the DTC to be operable as the digital transactiondocument associated with the selected one LDTDP. In other embodiments, amethod of conducting digital transactions using a digital transactionapparatus that recognises a plurality of LDTDPs is provided, each LDTDPrepresenting a digital transaction document and including one or more ofa unique ID or a token associated with the unique ID for performing adigital transaction with at least one digital transaction device, thedigital transaction apparatus further including, an LDTDP storagememory, a staging memory, a DAD, and a DTC, the DTC including a DTPUhaving a secure record memory, the method including, operating the DADto select one of the at least one LDTDPs stored in the LDTDP storagememory, copying a selected one LDTDP from LDTDP storage memory tostaging memory, copying the selected one LDTDP from staging memory tothe secure record memory thus enabling the DTC to be operable as thedigital transaction document associated with the selected one LDTDP. Inthese embodiments, the known operation of the existing DTPU, such as anEMV device, is exploited to place data pertaining to a particularpersonality in the memory location that will be accessed by the EMVdevice to establish the personality of the DTC.

In various embodiments, the digital transaction document may be a creditcard, debit card, bank account, store card, passport, identity card, ageverification card, loyalty card, government agency card, driver'slicense, and/or various other kinds and types of digital transactiondocument, which would be typically implemented as cards, documents orbooklets, or implemented electronically. It will be understood that inthis specification the term “logical” refers to a set of characteristicsfor each of the digital transaction documents, and those characteristicsmay be in part, or all, contained in an LDTDP representing the documentor logical document. The characteristics may include data such as aunique ID for the digital transaction document, ownership informationand expiry dates. The unique ID information may be a unique ID number. Achange in the DTC parameters adopted by the DTPU from expressing onedigital transaction document to expressing another digital transactiondocument may also be referred to as a change in the DTC “personality”.In addition to changing parameters in a DTC such that it adopts apersonality for the purpose of future transactions, in one particularembodiment, the DAD is operable to receive data pertaining to newpersonalities by accessing a website and is further operable to transmitrelevant data/instructions to the DTC to adopt the personality of thenewly acquired personality obtained by the DAD.

In embodiments, an LDTDP may include the unique ID and a tokenassociated with the unique ID, the unique ID and token both associatedwith the digital transaction document represented by the LDTDP. In otherembodiments, the LDTDP may include only the unique ID associated withthe digital transaction document. In yet other embodiments, the LDTDPmay include only the token associated with a particular unique ID, theunique ID (and, therefore, the token) associated with the digitaltransaction document.

In some embodiments, each of a number of digital transaction documentsmay be associated with a single unique ID and a single token associatedwith the unique ID, each of some other digital transaction documents maybe associated with a single unique ID and a number of different tokensassociated with the unique ID, and each of yet other digital transactiondocuments may not be associated with any token (in which case such adigital transaction document will be associated only with a unique ID).In these embodiments, the unique ID and/or token for a digitaltransaction document (or logical digital transaction document) will becontained in an LDTDP. Where a document has a number of associatedtokens, each token or tokeniunique ID pair, may be in a separate LDTDP.In embodiments, the unique ID for the digital transaction documentcontained in the LDTDP may be a Personal/Primary Account Number (PAN) ifthe document is a credit/debit type card, or similar kinds of uniqueID's, such as unique alphanumeric ID's or unique names.

In some embodiments, the at least one of the plurality of LDTDPs isstored on the DAD, wherein the LDTDP storage memory is located on theDAD. In other embodiments, the at least one of the plurality of LDTDPsis stored in LDTDP storage memory located on the DTC, wherein selectionof a LDTDP through the DAD is effected by an icon, name or otherindicator associated with the LDTDP, although the LDTDP is not itselfstored on the DAD. In this example, the selection of the LDTDP iscommunicated to the DTC by data indicating which LDTDP has beenselected, and the DTC implements the selected LDTDP from its LDTDPstorage memory based on the indicative data.

In yet other embodiments, a part of each of the at least one of theplurality of LDTDPs is stored on the DAD. Another part of eachcorresponding at least one LDTDP is stored on the DTC, wherein theselection is based on the part stored on the DAD. The part of the LDTDPselected is transmitted to the DTC, and the determination of which partof the LDTDP matches the selected part is made on the DTC. In this way,the two parts of the LDTDP can be combined to form the whole LDTDP,which can then be implemented by the DTC. In such an embodiment, theLDTDP storage memory is split between the DAD and the DTC.

In an embodiment, the DAD is enabled to store and provide for selectionof an LDTDP, which is implemented as a digital transaction document onthe DTC. The selection of the document associated with an LDTDP (orselection of the LDTDP) may occur before selection of a token associatedwith the LDTDP. Where a document has only one associated token, theselection of the document may be selection of the associated token,since a further selection process is not required. In some embodiments,selection of a token automatically indicates which LDTDP is to beselected, since the token is associated only with one document (or oneLDTDP).

In another embodiment, the user may select an LDTDP and a predeterminedtoken is selected based on context determined by the DAD. For example,if the DAD determines different locations, then a token can beautomatically selected based on the determined location.

In various embodiments, some digital transaction documents contained inan LDTDP will have only one associated token and other digitaltransaction documents will have multiple associated tokens. It will beunderstood that embodiments described in this specification include bothoptions, unless otherwise stated or unless the inclusion of both optionsresults in an embodiment that is not possible to implement.

In various embodiments, some identifying information in respect of adigital transaction document contained in an LDTDP will not need to bestored in the apparatus LDTDP storage memory (either in the devicememory or the card memory) since the token(s) stored in the apparatuswill be sufficient to identify its (their) associated digitaltransaction document(s). For example, where the digital transactiondocument is a credit card, the card number (the PAN) is not contained inthe LDTDP and instead, the tokens associated with the credit card aresufficient to identify the particular credit card. In such an example,the credit card PAN may include the typical 4 leading digits whichidentifies the card as being of a certain type or brand (MasterCard,Visa, etc.). A token for the particular credit card may have the samefour leading digits, but with different remaining digits, so that thetoken identifies the card with which it is associated. It will beunderstood by skilled readers that not having a PAN, for example,contained in the respective LDTDP and stored in the apparatus LDTDPstorage memory (either in the DAD memory or the DTC memory) shouldincrease security for the associated digital transaction document. Insuch examples, only the digital token containing LDTDPs are selected bythe DAD, with the associated digital transaction document beingautomatically identified and selected.

In one embodiment, the DTPU CPU operates to copy data from the stagingmemory (staging area) to the EEPROM, or a part of the EEPROM, which hasbeen set aside for secure record memory (secure element). In otherembodiments, the DTPU CPU operates to copy part of the data from thestaging memory to a part of the EEPROM, which has been set aside forsecure record memory, and another part of the data to part of the EEPROMwhich has not been set aside for secure record memory. When, forexample, an LDTDP is copied into secure record memory (secure element),the DTPU uses the digital transaction document information from theLDTDP (unique ID, token, commencement date/time, expiry date/time, etc.)to attain a personality, such that the DTC operates as the associateddigital transaction document with the document's associatedcharacteristics, such as commencement date/time, expiry date/time, etc.

It will be understood by skilled readers that a particular digitaltransaction document may be represented by one or more LDTDPs. Forexample, a digital transaction document associated only with a unique IDwill be represented by a single LDTDP including that unique ID. In thisexample, the LDTDP being copied to secure record memory (which may bereferred to as a secure element, or a secure element area) causes theDTC to operate as the digital transaction document associated with theunique ID.

In another example, a digital transaction document associated with aunique ID and a single token may be represented by a single LDTDPincluding the unique ID and the token. In this example, the LDTDP beingcopied to secure record memory (secure element) causes the DTC tooperate as the digital transaction document associated with thetokenized unique ID. Alternatively, a digital transaction documentassociated with a unique ID and a single token may be represented by twoLDTDPs, one of which includes the unique ID, the other including thetoken. In this alternative example, the LDTDP including the unique IDbeing copied to secure record memory (secure element) causes the DTC tooperate as the digital transaction document associated with the uniqueID (untokenized), whereas the LDTDP including the token associated withthe unique ID being copied to secure record memory (secure element)causes the DTC to operate as the digital transaction document associatedwith the tokenized unique ID.

In yet another example, a digital transaction document associated with aunique ID and multiple tokens may be represented by various LDTDPsincluding both the unique ID and one of the multiple tokens, or could berepresented by one LDTDP containing the unique ID, and a number of otherLDTDPs, each containing one of the multiple tokens associated with theunique ID associated with the digital transaction document representedby all the LDTDPs, wherein the one of the LDTDPs being copied to securerecord memory causes the DTC to operate as either the digitaltransaction document associated with the tokenized unique ID, or thedigital transaction document associated with the untokenized unique ID.

Other arrangements for the LDTDPs may be contemplated, depending on thenature of the digital transaction document represented by the LDTDP (orLDTDPs).

In some embodiments, an LDTDP may also contain further data associatedwith a digital transaction document, such as an expiry date for thedocument. It may also be desirable in some circumstances to havemultiple expiry dates in an LDTDP, for example, one expiry date for theunique ID (or for the associated digital transaction document) andanother expiry date for a token associated with the unique ID. It willbe understood that, where a digital transaction document has a number ofassociated tokens, each token may have a different expiry date, whichwill be contained in the respective LDTDP.

Further, the LDTDP for some digital transaction documents may include acommencement date, so that the period between commencement of validityand expiry of validity of the document (and/or one or more tokensassociated therewith) can be controlled. For example, it may bedesirable to have the digital transaction document valid for only oneday if the document is a door pass, or some other card or pass, with ashort validity requirement. Moreover, the commencement and expiry in theLDTDP could include times as well as dates for finer control of thevalidity period of the digital transaction document (and/or one or moretokens associated therewith).

In other embodiments, the further data contained in an LDTDP may includea security code associated with the unique ID of the document, and mayalso include a number of other different security codes associated withone or more tokens also contained in the LDTDP. For example, where thedigital transaction document is a credit card, the security codes may beCard Verification Value 2 (CVV2) security codes, or similar. In thisexample, the unique ID is a PAN, which has an associated CVV2 securitycode, and the PAN has, perhaps, five associated tokens, each token alsohaving an associated CVV2.

In yet other embodiments, the LDTDP may contain a PersonalIdentification Number (PIN) for the digital transaction document. Theremay be one PIN associated with the unique ID of the document, and other(different) PINs, each associated with a token. In some embodiments, thePINs could be One-Time PINs (OTPs), which expire after being used for asingle transaction. In other embodiments, the PINs may have a limitedperiod of validity, for example, expiring one week after first use.

In other embodiments, the LDTDP may contain other data, such as name,date-of-birth, physical characteristics, and other personal data of aperson who owns the digital transaction document. For example, if thedigital transaction document is a passport, for certain transactions anLDTDP containing the passport unique ID and eye color of the owner maybe desired for authentication and/or verification in such transactions.

The LDTDP may be described as including, containing, wrapping orembodying a unique ID, token and/or other data. Further, the LDTDP maybe encrypted (or otherwise secured) to protect the data contained in theLDTDP. In yet other embodiments, the LDTDP may be secured by using apublic/private key infrastructure. The public and private keys may beissued by, for example, the DTCs primary issuer. Alternatively, thepublic and private keys may be issued by a primary issuer of an LDTDP,for example, a credit card provider.

In some embodiments, the DTPU may include a System Input/Output (SystemI/O) for inputting and outputting data and/or encrypted data to and fromthe DTPU. The System I/O is a means by which the LDTDP can be copiedinto secure record memory (secure element), allowing the DTPU to operatewith the personality of the logical digital transaction documentcontained in the LDTDP. The secure element could be located on one ormore devices. It could also be located in a single device with a virtualpartition, or a folder.

The DTPU may also include a processor, or Central Processing Unit (CPU),which operates to control the DPTU. Further, the DTPU may include acrypto-coprocessor for encrypting and decrypting data efficiently, thusallowing the DTPU CPU to operate more efficiently without having theburden of encryption and decryption tasks. In some embodiments, the DTPUCPU and crypto-processor co-operate to decrypt (unwrap, unpack, orotherwise deal with) a selected LDTDP, before or while being stored insecure record memory, such that the DTPU can operate with data from theLDTDP.

The DTPU may also include various different types of memory, such asRead Only Memory (ROM), Random Access Memory (RAM), and ElectricallyErasable Programmable Read Only Memory (EEPROM). In some embodiments,one of the types of memory can be used for the secure record memory(also known as a secure element), with one of the other types of memoryused for the staging memory (which may also be referred to as a stagingarea). Any one of the abovementioned types of memory could be used asLDTDP storage memory.

In some embodiments, the DTPU is an EMV device, or a device thatconforms with one or more EMVCo specifications. In other embodiments,the DTPU is an EMV device (otherwise conforming to one or more EMVCospecifications), which is constructed to read a secure storage area(staging memory/staging area) for the purpose of establishing thepersonality of the card in which the DTPU is installed. The securestorage area, or staging memory, may be within the constructed EMVdevice, within the constructed EMV device storage area (memory), orwithin some other secure memory.

In embodiments, the CPU of the DTPU and/or a CPU that is external to theDTPU but resident within the DTC (referred to as an external DTCprocessor) is activated only after the CPU or the external CPU securelyidentifies itself to a linked DAD, such as a smartphone. In someembodiments, linking between the DAD (for example, a smartphone) and theDTC uses strong encryption for the ID and transfer of data. Links may beunique to each set (smartphone and DTC).

In embodiments, the linking between the DAD and the DTC is wireless, andmay be formed using respective transceivers of the DAD and DTC. In yetother embodiments, the DTC is linkable” (i.e. operable to establishcommunications) with the DAD using a physical connection, such as a datacable. In such embodiments, the data cable may be adapted at one end toplug in to a communications port, such as a USB port, on the DAD, withthe other end adapted to clamp or clip on to a part of the DTC. The DTCmay have electrodes, or metal plates at or towards an edge thereof toconnect with the cable when clamping or clipping the other end of thedata cable to the DTC. In some embodiments, the respective transceiversfor the DAD and the DTC may be suitable for Bluetooth™, Low EnergyBluetooth™, Wi-Fi, NFC, ANT+, or other types of contactless, or wirelesscommunication transceivers. In embodiments, the DTC may include abutton, or a similar device, to activate linking with the DAD.

In various embodiments, the DAD is operable to transfer data to the DTCwithout the formation of a direct link between the DAD and DTC. In suchembodiments, the DAD is used to transfer data, for example, via theinternet to a (cloud) connected third party device. A link between theDAD and the third party device for the data transfer can be temporary,and that link can be terminated once the data has been completelytransferred. The third party device is connected, for example, to anetwork (perhaps via another third party, such as a payment processor),which enables the third party device to form a link and communicate witha digital transaction system device, such as a Point Of Sale/ElectronicFunds Transfer at Point Of Sale (POS/EFTPOS) terminal or AutomaticTeller Machine (ATM), subsequent to forming a link with the network andthence to the digital transaction system device. The third party deviceis enabled to transfer the data previously received from the DAD to thedigital transaction system device. A holder of a DTC (which may be aperson different from the owner and/or operator of the DAD) can take theDTC to the digital transaction device, and by insertion, or placing theDTC proximal to the device, the DTC holder can obtain data from thedigital transaction system device. In this way, data from the DAD can betransferred indirectly and asynchronously to the DTC. This indirect datacommunication between the DAD and the DTC can also be reversed such thatthe DTC indirectly and asynchronously transfers data to the DAD, perhapsusing the same infrastructure of the digital transaction system device,the network including the payment processor, the third party device andthe internet. It will be recognised that the indirect and asynchronousdata transfer may be useful where a first person has a DAD and wants tosend data to a DTC in the control of a second person who isgeographically remote from the first person. For example, a motheroperating her DAD may prefer to increase spending limits of a DTCoperated by her son who is travelling in a foreign country.

In embodiments, the external DTC CPU controls the reading and re-readingof the DTPU (for example, an EMV device), and updating the memorycontents of the DTPU.

In embodiments, a DTC includes a wearable payment device such as a watchbut also includes payment devices that are incorporated into pieces ofjewellery such as finger rings, bangles and pendants. The DTC could alsocomprise an implantable payment device, which includes chip andtransceiver arrangements which may be suitably configured forsubcutaneous implantation.

In other embodiments, the DAD may be a smartphone, or another suitabledevice such as a fob, or key fob, or a portable processing device withan internal/external wireless communications capability such as an NFCreader/writer which is configured to operate as a DAD. In someembodiments, the DAD may be, or may include a wearable device, such as awatch or other piece of jewellery. In this regard, some smartphonespresently operate with wearable wrist (or watch-like) devices. It isenvisaged that future smartphones may be wholly incorporated into awearable device, and that the DAD can be such a device. In thecircumstance that the DAD includes a smartphone operating with awearable wrist (or watch-like) device, the wearable component may haveits own unique ID, which can be used for securing linking and datatransfer between the DAD and the DTC in cooperation with unique IDs,respectively, for a smart phone and the DTC.

In other embodiments, the DAD (smartphone), after securely connecting tothe DTC, uploads correctly formatted data in an LDTDP to the nominatedsecure storage area (staging memory or staging area) and then transmitsan instruction to either the DTPU CPU or the external DTC CPU to checkif the nominated storage area contains the data in a specified format(e.g. a compliant LDTDP). If the data satisfies the specified formatrequirements and passes various checks, the DTPU CPU or the external DTCCPU copies or moves the data (LDTDP) to a specified area (secure recordmemory/secure element) within the DTPU (for example, within the EMVdevice). The DTPU CPU or the external DTC CPU then transmits aninstruction to the DTPU (EMV device) to read the data (LDTDP) within thesecure record memory and act according to the data (express the LDTDP asthe associated digital transaction document) contained within thissecure record memory (secure element). The DTPU CPU or the external DTCCPU can be programmed to search for specific headers and/or other dataidentifiers within a range of parameters before acting. In otherembodiments, it is possible to copy all records of all LDTDPs to thestaging memory, and to use an index to reference the selected LDTDP fromthose records. Copying all records in this manner reduces therequirement to write to and/or read from the staging memory, andtherefore reduces risks of accessing that memory area, includingsecurity risks.

In some embodiments, the secure record memory (secure element) islocated in the DTPU, the staging memory (staging area) is locatedexternal to the DTPU on the DTC, and the LDTDP storage memory (storagememory or a memory location) is located on the DAD. In otherembodiments, the secure record memory (secure element) could be locatedwithin the external CPU on the DTC. Further, the LDTDP storage memoryand/or the staging memory (staging area) could be located outside of theDTC, for example, as additional memory located on the DAD. Whilst thesecure record memory (secure element) could be located outside of theDTPU, this arrangement could be considered less secure than locating thesecure record memory within the DTPU. However, any security concernscould be mitigated by encrypting any data in a secure record memorylocated outside the DTPU. In yet other embodiments, the LDTDP storagememory could be located elsewhere other than the DAD or the DTC, and,for example, the LDTDP storage memory could be located in a cloud basedstorage system, or could be located on portable memory, which can beaccessed from the DAD.

In embodiments, the DTC includes a card transceiver. In otherembodiments, the DTC includes a Graphical User Interface (GUI) fordisplaying data associated with the digital transaction document ortoken associated with the selected or implemented LDTDP. For example, ifthe logical digital transaction document is a credit card, the GUI onthe DTC may display the PAN, the selected token associated with theselected LDTDP containing the logical digital transaction document, thecard brand logo, the expiry date of the credit card, and may alsodisplay a virtual, or mimicked, hologram of the credit card brand. Inanother embodiment, the DTC may only display the selected token,including the expiry data and/or the CVV2, and not the associated PAN.The DTC may also include a real hologram displayed somewhere on itssurface.

The external DTC CPU (or external processor) may control operationsexternal to the DTPU and/or control reading/writing and otherinput/output operations with the DTPU via the DTPU system I/O. Theexternal DTC CPU may also accommodate security tasks external to theDTPU, and/or control the GUI. In some embodiments, the external DTC CPUmay include firmware that is operable to write data (for example, LDTDPdata) to staging memory, such that, when the DTPU is activated, the DTPUcopies the data to secure record memory (secure element) in the DTPU. Inembodiments, the firmware on the external DTC CPU may be updated and theDTC is provided with means for enabling firmware updates. The updatesmay include firmware that extends functionality of the DTC and anyprograms and/or applications running thereon. The updates may allow forcorrection or amendment of existing firmware functions that have beenidentified as faulty or sub-optimal. Other firmware updates may beissued to improve or extend security, or secure functioning of the DTC.The ability to update firmware may be contrasted with, for example,existing credit or debit cards using EMV devices, where there is no, orlimited, ability to update the EMV firmware. Presently, firmware is“updated” by replacement of a credit card or debit card when it expires.In the circumstances that the DTC has a relatively long operationallife, for example, 5 years or more, updating firmware during theoperational file of a DTC enables the functionality of the DTC to beimproved or enhanced without requiring return of the DTC to an issuingauthority.

In embodiments, the DTC may only form a communications link with one DADto the exclusion of all other DADs representing a secure communicationslink and transmission of data between the DAD and the DTC by respectivetransceivers (the DTC transceiver and the DAD transceiver). In someembodiments, the link is a secure/encrypted link. In other embodiments,each DAD may be linked with multiple DTCs. However, in this embodiment,each DTC may link with only one DAD, to the exclusion of all other DADs.

In embodiments, the linking between the DTC and the DAD may beimplemented by using a unique identifier for the DTC and another uniqueidentifier for the DAD. In some embodiments, the linking of the DTC andthe DAD may occur (at least partially) before the DTC is sent to a user.For example, the linking may be implemented by a DTC issuer, including abank, a card issuing facility, a card “personalization” facility, orother type of third party institution capable of implementing a“partial” linking. In one example, a partial linking may be implementedby the DTC issuer establishing the DTC and providing an applicationready for download by a user to the user's DAD (for example, asmartphone), wherein activating the application causes the smartphone tosearch for, and link to, the DTC issued to the user. In otherembodiments, the linking may be implemented by the user, and may occurwhen the user receives the DTC.

In some embodiments, the linking between the DTC and the DAD ispermanent, or semi-permanent, and cannot be unlinked, or re-linkedwithout permission and required action from, for example, one of thepreviously-mentioned third parties. For example, to unlink a DTC and theDAD uniquely linked to it, a unique code may be entered on the DAD anduploaded to the DTC. This will reset the DTC to a default state. In thedefault state, the DTC could “look” for a new specified uniqueidentifier for a different DAD (for example, an IMEI number, or anothersuitable unique ID, of a smartphone). This unlinking/re-linking may beuseful when the user replaces their DAD, such as a smartphone. In yetother embodiments, the linking may be temporary, and performed by theuser. For example, a user may form a link a short time before anintended transaction is to occur, and, may unlink after the transactionis completed and at a predefined short duration after the transaction.

In an embodiment where the DTC and the DAD are dynamically linked (thatis, linked by the user at a chosen time), the linking and selecting ofthe desired LDTDP from the DAD can occur in any order.

In embodiments, in order to have secure communication between the DTCand the DAD, the security may be implemented by linking the transactioncard and the DAD, or the security may be implemented for datatransmission between the transaction card and the DAD. In otherembodiments, the security may be implemented for both the linking andthe data transmission.

In some embodiments, the DTC includes a battery or capacitor to provideelectrical power for memory storage. For example, embodiments of thecard may include non-static type memory storage or, some form of poweredtransceiver, such a as Bluetooth™ transceiver. A battery can also beused to power the DTC to process encryption, and for changing the LDTDPcontaining the digital transaction document and/or digital tokenexpressed by the DTC by implementing changes in the LDTDP containing thelogical digital transaction document and/or the associated digitaltoken.

In some embodiments, the DAD includes a processor, a user interface, adevice transceiver and device memory. In various embodiments, the DADmay be a smartphone, computer tablet, laptop, Personal Computer (PC),fob device, or other suitable equipment capable of operating to allow auser to select an LDTDP and transmit data representing that selectedLDTDP. The DAD may also be a custom built device suitable for thepurpose. In other embodiments, the DAD may be a wearable device, such asa smart watch, or could be enabled to operate with such a wearabledevice. In embodiments where the DAD has a user interfaces capable ofdisplaying images, the user interface may display a Card AssociationScheme logo along with the name or other alphanumeric indicator of apersonality. In the instance of a credit card, the display of a CardAssociation Scheme logo on the DAD user interface should appease CardAssociation Scheme providers who would otherwise prefer a physical carddisplaying that logo permanently.

In an embodiment, a selection is made from the user interface, which mayinclude selecting from a touch activated screen, for example, on asmartphone. The touch activated screen may operate by displaying lists,drop-down lists, or other screen designs, or may employ icons on thescreen. In an alternate embodiment, the user interface may be a simpledisplay with buttons, for example, on a fob, or a key fob. Where the DADis a PC or laptop, it may employ a screen and keyboard to provide a userinterface. However, the DAD is generally preferred by users to be aportable device. On the DAD screen, an LDTDP may be representedsymbolically with an icon relevant to the associated (logical) digitaltransaction document, or could use names or nicknames for the LDTDP. Thenames or nicknames could be assigned by the user, or a service provider.

For example, the document might be a MasterCard credit card and theLDTDP associated with the MasterCard may be represented on the DADscreen by a MasterCard logo. Additionally, or alternatively, the LDTDPmay be represented by a combination of icon and alphanumericinformation. For example, where a MasterCard has one or more associatedtokens, each token contained in a separate LDTDP, the LDTDP for eachMasterCard token may be represented on the DAD screen by the MasterCardlogo and at least a part of the respective token number.

In various embodiments, the digital transaction devices may includePOS/EFTPOS terminals, ATMs, internet connected computers or personalcomputers, and other such electronic devices. The digital transactiondevice may also include infrastructure such as a telephone and callcentre enabled for Mail Order/Telephone Order (MOTO) type transactions.

In embodiments, the DTC and the digital transaction device may interfacewith each other by various methods. In some embodiments, the interfacemay be effected by insertion of the DTC into the digital transactiondevice. In other embodiments, the interface between the transaction cardand the transaction device may be effected by Near Field Communication(NFC), wherein the card and/or the device each have a transceiver andantenna for communication. In yet other embodiments, the DTC may includea magnetic stripe, wherein the digital transaction device includes amagnetic stripe reader. In yet other embodiments, the DAD may include atransceiver configured for communication with the digital transactiondevice, so that transactions can optionally be made directly through theDAD. In yet other embodiments, the DTC is configured to be inserted intoan POS/EFTPOS terminal, or an ATM, and is approximately the same size asa credit/debit card.

In further embodiments, the DTC may have a magnetic stripe, and the DADmay have a magnetic stripe reader and/or writer.

In an embodiment, the DTC may be adapted to express a default “Null”personality, wherein the data in place of an LDTDP containing a logicaldigital transaction document requiring unique identification could be apredetermined series of digits, for example, all zeros. In one example,where the logical digital transaction document represented by an LDTDPis a credit card, the unique identification may be the credit card PANor an associated digital token, and setting the DTC back to expressing aNull personality is performed by over-writing or replacing the PAN orthe associated digital token with all zeros. This may occur by writingto the staging memory and copying into the secure record memory, or byhaving the DTPU itself write into secure record memory (secure element).

In an optional embodiment, the DTC may be configured to store an LDTDPfor an associated logical digital transaction document and/or associateddigital tokens for a chosen period. The period may be predetermined bythe issuer of the DTC and/or issuer of the digital tokens (which may bea different issuer to that of the DTC). Alternatively, the storageperiod may be chosen by the user. In other variations, the period may bedynamically selectable, and could be chosen by the user for eachtransaction, or for each selection and storage of a single LDTDP for anassociated logical digital transaction document and/or associateddigital token(s) on the DTC. In other embodiments, the storage periodfor the LDTDP for an associated logical digital transaction documentand/or associated digital token(s) on the DTC could be determined basedon the LDTDP selected, the transaction type, or both.

In yet another embodiment, the DTPU of the DTC is configured tostore/express the personality associated with only one LDTDP containinga logical digital transaction document and associated digital token(s)at any particular time. In this regard, to change the LDTDP in the DTPU,a user must overwrite or delete a previously-stored/expressed LDTDPcontaining a logical digital transaction document and its associatedtoken(s) if there is one embodied in the DTC at that time. In anotherembodiment, the card may be configured to store/express more than oneLDTDP (containing a logical digital transaction document and theassociated token(s) for each document) concurrently.

In another embodiment, the DTC and its DTPU may be configured to storeand/or express an LDTDP associated with a primary logical digitaltransaction document and its associated token(s), and one LDTDPassociated with a secondary logical digital transaction document and itsassociated token(s). In yet another embodiment, the DTC and its DTPU maybe configured to store and/or express one LDTDP associated with aprimary logical digital transaction document and its associatedtoken(s), and one or more LDTDP associated with secondary logicaldigital transaction documents and associated token(s) for each. TheLDTDP associated with the primary logical digital transaction documentand its associated token(s), in some embodiments, may be storedpermanently on the DTC in its DTPU, with the one, or one or more, LDTDPsassociated with secondary logical digital transaction documents and theassociated token(s) for each being temporarily stored on the DTC in itsDTPU. In yet other embodiments, the one, or one or more, LDTDPsassociated with secondary logical digital transaction documents and theassociated token(s) for each may be permanently stored and/or expressedon the DTC in its DTPU and referenced by a code stored on the DAD.

In yet other embodiments, the DAD may include an e-wallet, which can beconfigured to operate with one or more of the LDTDPs containing logicaldigital transaction documents and associated token(s) stored on the DAD.This arrangement can be used to top up funds where the associateddigital transaction document is a debit card or a credit card. Further,the DAD may include functionality to allow a user to view transactionsthat are completed with the DTC (or by other means, such as onlinetransactions) in real time. This may allow the user to monitor alltransactions made by all LDTDPs associated with digital transactiondocuments in the apparatus (which may include a plurality of DTCs linkedor linkable with the DAD) in, a single screen or with a singlesmartphone application. Further, the user could be shown the associateddigital token that was used for a transaction. This may further allowthe user to cancel, stop, pause or otherwise appropriately deal with oneor more digital transaction documents if the user detects or perceivesthat one or more digital transaction documents have been misused orfraudulently used. The apparatus could also be adapted to allow the userto cancel, stop, pause or otherwise appropriately deal with one or moredigital transaction documents on a token-by-token basis, so that onlycertain tokens associated with a document are disabled, but the documentis still useable with other associated tokens. The user could alsocancel, stop, pause or otherwise appropriately deal with one or morelogical digital transaction documents if the user seeks to limit, forexample, spending, or other financial or non-financial transactionsoccurring with one or more logical digital transaction documents. Thismay also be performed on a token-by-token basis.

In another embodiment, the DAD may be enabled to receive alerts for theuser when a transaction, or a selected category or type of transaction,is conducted using the DTC. For example, the DAD may alert the user thatan LDTDP containing a digital transaction document, such as a passport,has been used for identification at an airport. Further, the alerts canbe implemented on a token-by-token basis. In another example, the DADmay alert the user that a credit card has been used to purchase servicessuch as a taxi ride, not included in a list of authorized transactioncategories, such as purchases of fuel and groceries, selected by theuser.

In other embodiments, the DAD and/or the DTC may be configured to allowa user to classify transactions into categories. The categories could bepredefined and/or defined by the user. The categorization could beconfigured in order to allow the user to monitor and/or limittransactions, such as spending with credit within that category. Acategory may be related to only one LDTDP and associated (logical)digital transaction document, or could be related to a number of LDTDPsand respective associated (logical) digital transaction documents.Tokens can also be used for categorization of transactions using the oneLDTDP and associated digital transaction document.

In yet another embodiment, the DAD may be configured to allow the userto transfer funds to another user who has a DAD. The transfer may belimited to same or similar LDTDPs and associated (logical) digitaltransaction document types, and could be limited in amount. In a furtherembodiment, the DTC could be configured to transfer funds to another DTC(owned by the user or owned by another user), or to another DAD (ownedby the user or another user).

Furthermore, in another embodiment, third parties, such as financialinstitutions, police, customs, government, employers, spouses, parentsand other interested parties could be authorized and enabled to cancel,stop, pause or otherwise appropriately deal with (including temporarysuspension) one or more LDTDPs containing logical digital transactiondocuments in the apparatus or selected token(s) associated with thedocument. This may be useful, for example, if a user has a gamblingaddiction, and prefers to have a third party monitor and prevent accessto credit cards, debit cards, bank accounts or other kinds of financiallogical digital transaction documents in order to prevent the user fromexcessive gambling. In the instance of an attempted fraudulenttransaction and cancellation/re-issuance of a logical digitaltransaction document, the user may be provided with alerts advising thecancellation of a document and the availability of a replacementdocument for collection/download to a user's DAD and subsequent use toeffect a transaction with a DTC adopting the personality of the newlyissued (replacement) document.

In other embodiments, the DAD may be configured to store datarepresenting loyalty points, frequent flyer points, or other associatedtransaction related documents, attached to a (logical) digitaltransaction document contained in an LDTDP, or plurality of (logical)digital transaction documents contained in respective LDTDPs. The DADmay also be enabled to update loyalty points, frequent flyer points andother associated transaction related documents during or after atransaction, or at other times. For example, loyalty points may be usedduring a transaction to reduce the cost of an item to be purchased usingthe DTC and the DAD. The DAD may also be enabled to add loyalty points,frequent flyer points and other associated transaction related documentsif a user visits a particular shopping store, or is in a predeterminedproximity of the store. In some embodiments, the loyalty points,frequent flyer points and other associated transaction related documentsmay be contained in an LDTDP as further data associated with therelevant (logical) digital transaction document and/or associatedtokens.

In yet another embodiment, if the DTC includes an LDTDP containing aprimary logical digital transaction document, for example, permanentlystored and/or expressed on the DTC in the DTPU, the primary logicaldigital transaction document may be a false or fake logical digitaltransaction document, such that data copied from the DTC or DTPU whereonly the primary logical digital transaction document is stored on theDTC or DTPU will be useless for any digital transactions. Alternatively,the primary logical digital transaction document may be represented by aunique ID that is incomplete, expired or all zeros, such as a Null ID.For example, where the primary digital transaction document is a creditcard, the PAN of the card could be incomplete, expired or all zeros. Inthis embodiment, only LDTDPs containing secondary logical digitaltransaction documents stored on the DTC and/or in the DTPU will be realand useable for a digital transaction when embodied on the DTC via theDTPU as a digital transaction document. Further, an LDTDP containing asecondary logical digital transaction document and its associateddigital token(s) may be stored or embodied as a tokenized digitaltransaction document on the DTC and/or expressed in the DTPU for only ashort period, for example, five minutes, in order to reduce the risk oftheft of data representing the digital transaction document and token.This arrangement reduces the risk that an unauthorized user can emulatethe associated digital transaction document and token. Alternatively,the LDTDP containing the primary logical digital transaction documentstored on the DTC and/or expressed in the DTPU may comprise incompletedata, rendering the DTC/DTPU unusable for digital transactions until auser downloads and saves secondary data to the DTC/DTPU (along withassociated token data), to render the primary logical digitaltransaction document complete and useable for digital transactions.

In yet another embodiment, each LDTDP or a sub-set of LDTDPs stored on aDAD may have a PIN associated therewith (or contained therein). The PINmay be a static PIN, or could be a dynamically generated PIN. In otherembodiments, the PIN may be displayed on the user interface of the DAD.Access to the PIN to display on the screen of the DAD may be by securedmethods, such as finger swipe or other such security methods such asthose commonly implemented on smartphones. In another embodiment, theDAD may be configured to allow the user to update a PIN for a particularLDTDP or for a number of LDTDPs. In embodiments, PIN's could also beassociated with particular tokens for a document in an LDTDP, such thateach token for the document has a different PIN.

In an embodiment, the method includes operating the activated DTC withthe digital transaction device to perform the digital transaction.

In some embodiments, tokens are provided for an LDTDP associated with aprimary logical digital transaction document before the DTC is issued toa user. The tokens can be sent to the DAD through a secure network sothat a token can be selected for a transaction with the associated LDTDPfor the logical digital transaction document (already stored on the DTCor in the DTPU at issuance) at the time of a transaction. Alternatively,the tokens associated with the primary document could be loaded onto theDTC or DTPU at issuance, with selection effected by the DAD at the timeof a transaction. Secondary logical digital transaction documents(optionally contained in LDTDPs) may be issued to the user through asecure network means to the DAD after issuance of the DTC, and theassociated digital tokens for each secondary document can be issued withthe associated secondary document (also optionally contained in therespective LDTDPs).

In yet another embodiment, tokens contained in one or more LDTDPs can bea fixed or extendible pool, which are used in a cyclical manner, with anext token selected in order. Alternatively, tokens could be selectedfrom the pool randomly (or pseudo-randomly). In a further embodiment,tokens could be one use only, with a pool of used or expired tokensreplaced when every token in the pool has been used or expired. It isalso possible that the pool of tokens is replenished in advance of everytoken being used or expired, for example, when there are ten unused orunexpired tokens remaining in the pool, the user could be alerted to theneed for token replenishment. It will be understood that single usetokens can improve security for an associated digital transactiondocument (and its containing LDTDP), and for the transactions. Inanother embodiment, the user could choose when to replace tokens in thetoken pool. In this embodiment, the user could request a new pool or anextension of their existing pool of tokens from a token provider. Thenew tokens could be provided already contained in respective LDTDPs forstorage in LDTDP storage memory.

In a further embodiment, a primary user of a given digital transactiondocument could assign tokens to a secondary user of that document. Forexample, a primary credit card holder could assign token(s) from a tokenpool to a subsidiary holder of that credit card. This may be used as away to control the spending of the subsidiary credit card user tolimits, amounts or categories of spending.

In yet other embodiments, where tokens are assigned for usage in onlycertain transaction types, a third party, such as a token issuer,government agency or other controller of token usage, has authority toallow issuance of only tokens for selected transaction types. In oneexample, the authority controlling issuance of tokens may only allowtokens to be issued for a credit card that are for non-gamblingexpenditure.

In some embodiments, the tokens are generated only by a third partyprovider who issues the tokens to users (optionally already contained inrespective LDTDPs). The tokens may also be issued by another third partyprovider in other embodiments. Alternatively, in an embodiment, thetokens may be generated locally by the user, for example, by the DAD andstored into the LDTDP storage memory contained in LDTDPs. The locallygenerated tokens could be securely copied to a third party to be matchedduring a transaction to thereby authorize the transaction. A cryptogrammay be created containing a token, along with one or more of theassociated document's unique ID, expiry date, unique ID of the DAD,time, date, location, and various other random, pseudo-random ornon-random inputs. A cryptogram may also be created using, for example,a public key from the DTC, a public key from the LDTDP (for example, ifit is a credit card LDTDP), and/or a public key from the digitaltransaction device (for example, a POS/EFTPOS terminal). The cryptogrammay also be created using public keys from other sources. A cryptogramcreated using one or more public keys will contain the one or moretokens, and other ID's and data.

Although various security and convenience benefits are evident, to askilled person upon reading the specification, with one or morearrangements according to embodiments of the invention, to the presenttime there has not been a sufficiently effective, efficient, and/orsecure means and/or method for adapting a DTPU (such as an EMVCospecified device) to embody different personalities as compared with thepersonality of the DTPU that was initially installed.

Since the certification process for a DTPU (such as an EMVCo specifieddevice) is an extremely long and complicated process, it is particularlydesirable to provide a Digital Transaction Card (DTC) that is operableto selectively assume the personality of a number of different digitaltransaction documents without requiring any change or modification tothe hardware or essential operating firmware of a DTPU device that hasalready achieved certification for use in accordance with existingdigital transaction systems. A Digital Transaction Card (DTC) that isoperable to selectively assume the personality of a number of differentdigital transaction documents without requiring any change to the DTPUthat has previously been certified for use in digital transactionnetworks, enables the development of a DTC that comprises the desirablefeatures of selectively assuming the personality of one of a number ofdifferent digital transaction documents without the usual delayassociated with obtaining certification of a new, or modified, DTPU thatis operable to effect the additional functionality of the DTC that wasnot previously available.

Software Enhanced EMV Device

In an embodiment, additional software including data and/or instructionsthat define a personality is installed on an existing certified EMVdevice during runtime to enable the EMV device to adopt thatpersonality.

In an embodiment one or more single-personality Applets (e.g., such asJava Applets) are installed on a personality section of an EMV devicewhich is created at the time of initialization of the EMV devicecontaining data and/or instructions defining a personality, that is,prior to issuance of the EMV device (which retains certification sincethe action is conducted by an approved/certified entity). In such anembodiment, the EMV device is operable to receive and execute commandsfrom either a DAD or a DTC external processor, the commands being inaccordance with the Global Platform Standard. As will be understood, anEMV device executing commands that accord with the Global PlatformStandard remains within the certification parameters of the EMV devicesince Global Platform Commands are pre-approved since they constrain theactions that may be implemented by an EMV device executing such acommand.

In another embodiment the one or more single-personality Applets arestored in a secure location in an external DTC processor, such as aMicrocontroller Unit (MCU) for example, in a location secured bysoftware (encrypted) or by hardware (secure element). In thisembodiment, the EMV device contact plate must be secured so that thirdparties are unable to “listen in” (man in the middle attacks) to datathat is transmitted between the external DTC processor and the EMVdevice for the purpose of monitoring same, and to further ensure thatthird parties cannot inject commands during a session involvingcommunication between an EMV device and MCU. The external DTC processoronce instructed sends and installs the selected file (e.g. the Appletwith the selected personality)) to the EMV device by use of GPScommands, and the EMV device executes the commands.

In another embodiment, additional software is incorporated into anexisting certified EMV device to enable the EMV device to receive andinstall multiple personalities and further, implement an increasedcommand set as compared with current devices. In particular, theincreased command set enables the EMV device to receive and install dataand/or instructions defining multiple personalities and modify theoperational parameters and/or the status of the personalities by usingGlobal Platform Commands that are usually only executed by authorisedentities that issue EMV devices.

In an embodiment, a Multi-Personality Applet is installed onto an EMVdevice prior to issuance of the EMV device (which retains certificationsince the action is conducted by an approved/certified entity) and onceissued and in use, the EMV device effects actions to install multiplepersonalities and to effect further actions upon, and with, thepersonalities stored on the EMV device.

In an embodiment, digital transactions are performed with digitaltransaction devices with a DTC having a DTPU and a DTC receiver, and aDAD having a DAD user interface, a DAD transmitter and the DAD havingaccess to data pertaining to a plurality of DTC personalities, whereinthe DAD and DTC are operable to transfer data from the DAD to the DTC,wherein the DTPU includes a software module having instruction codewhich, when executed, causes the DTPU to receive and implementinstructions according with the Global Platform Standard (GPS), the DTPUsoftware module operable to receive a plurality of GPS commands issuedby the DAD responsive to user selection of a desired personality usingthe DAD user interface, thus causing the DTPU to adopt the user selectedpersonality and upon completion of execution of the plurality of GPScommands, the DTC operable to subsequently effect transactions as theuser selected personality.

In an embodiment, the user selected personality is communicated to theDTPU by the DAD. In another embodiment the DTPU seeks a data transferfrom the DAD which includes the user selection.

Embodiments in which existing DTPU hardware is not modified to effectthe functionality provided by the DTC in adopting one of many differentpersonalities is beneficial since the use of an existing DTPU hardwareis likely to require minimal re-certification (or perhaps avoid the needfor re-certification entirely) by a certification authority of the DTPU.

In embodiments in which the existing software of a certified DTPU ismodified to effect the functionality of a DTC operable to store andadopt one of many different personalities, any re-certification that isrequired is likely to be far less difficult and lengthy as compared withaltering the firmware of an existing certified DTPU. Accordingly, use ofGlobal Platform Standard (GPS) commands in the instance of an EMV deviceis beneficial since a DTC can be provided wherein only the EMV devicesoftware is enhanced as compared with an existing certified EMV device.

However, the issuance of GPS commands to effect functions in an EMVdevice requires the data transferred to effect those functions to beencrypted, or in some way isolated from the environment, to preventeavesdropping or man-in-the-middle attacks by persons seeking tointerfere with the legitimate transfer of data according to GPScommands. As will be understood by skilled readers, the use of GPScommands outside the confines of a secure issuing facility may require asecure session to be established for transmission of those commands inorder to retain the secrecy of same. Irrespective of the need to retainsecrecy, the establishment of a secure session ensures that theinjection of commands that are not intended is avoided. Further, despitethe absence of a single GPS command to effect a personality change, asequence of GPS commands are issued during a secure session to effect arequired change such as a user selected change to the personality of aDTC.

As will also be understood, encryption keys that are required to decryptthe parameters of a stored personality reside on the EMV device for eachpersonality and in one embodiment, a further set of limitedfunctionality encryption keys are available to unable changes to thestatus of stored personalities and a limited set of operationalparameters.

Firmware Modified EMV Device

Although a modification to the essential operating firmware of acertified EMV device causes the device to lose its certificationcredentials, it remains possible to implement an embodiment of theinvention with a firmware modification to an existing certified EMVdevice. Of course, once the firmware has been modified, re-certificationof the device with the modified firmware is required before the devicecould be used.

In this embodiment, the firmware of an existing EMV device is modifiedto enable the EMV device to receive and execute an increased set ofcommands from an external network transaction device (such as an ATM orEFTPOS device (or a device initiating a network transaction device))that enables the secure memory of the EMV device to be modified.

BRIEF DESCRIPTION OF THE DRAWINGS

For a better understanding of the invention, and to show how it may beperformed, optional embodiments thereof will now be described by way ofnon-limiting examples only and with reference to the accompanyingdrawings in which:

FIG. 1 is a diagrammatic representation of an apparatus in accordancewith an embodiment of the invention, including an embodiment of aDigital Transaction Card (DTC) and an embodiment of a Data AssistanceDevice (DAD) in the form of a smartphone, wherein the apparatus is beingused for a transaction with a digital transaction device, in thisexample, a Point of Sale/Electronic Funds Transfer at Point of Sales(POS/EFTPOS) terminal;

FIG. 2A is a diagrammatic representation of a DTC in communication withthe DAD of FIG. 1 operating to select a digital transaction document byuse of the DAD and selection of the personality of the DTC resultingfrom selection of the required personality on the DAD and communicationof same to the DTC according to an embodiment;

FIG. 2B is a diagrammatic representation of a DTC illustrating theselection of digital transaction documents by use of a DTC userinterface which in the embodiment of FIG. 2B includes various touchactivated switches and a display;

FIG. 3 is a diagram showing a Digital Transaction Card (DTC) and a DataAssistance Device (DAD), in this example, a smartphone, operating aspart of a system and method, where the DTC has a battery (rechargeablebattery) that is monitored, in accordance with an embodiment of thepresent invention.

FIGS. 4A, 4B, 4C and 4D are diagrammatic representations of variousembodiments of a DTC in the form of a watch, ring, smartphone protectivecase and a credit card body respectively, the credit card body of FIG.3D depicted according to a minimum viable product embodiment, withoutinterface embodiment and with interface embodiment respectively;

FIG. 5A is a diagrammatic representation of the elements in a softwareenhanced DTPU according to an embodiment of the invention involvingsingle-personality applets;

FIG. 5B is a diagrammatic representation of the elements in a softwareenhanced DTPU according to an embodiment of the invention involvingmulti-personality applets;

FIG. 6A is an abstract diagrammatic representation of a digitaltransaction card (DTC) according to an embodiment of the invention inwhich the DTC has been separated into four abstract layers for thepurpose of explaining the functionality that occurs in each of the fourdefined abstract layers when receiving commands from a DAD to effectchanges to the DTC personality;

FIG. 6B is an abstract diagrammatic representation of a digitaltransaction card (DTC) according to an embodiment of the invention inwhich the DTC has been separated into four abstract layers for thepurpose of explaining the functionality that occurs in each of the fourdefined abstract layers when receiving commands from a DAD to effectchanges to the DTC personality;

FIG. 6C is an expanded representation of the Physical (Electrical) Layerof FIGS. 6A and 6B;

FIG. 7A provides a diagrammatic representation of data flows betweenindividual elements of a Digital Transaction Card (DTC) according to anembodiment of the invention when effecting a DTC personality change froma DAD; the Figures collectively providing diagrammatic support for anexplanation of an exemplary data flow and interactions betweenindividual elements on the Physical (Electrical) Layer of a DTCaccording to an embodiment of the invention;

FIG. 7B provides a diagrammatic representation of data flows betweenindividual elements of a Digital Transaction Card (DTC) according to anembodiment of the invention when effecting a DTC personality change byuse of the DTC interface, the Figures collectively providingdiagrammatic support for an explanation of an exemplary data flow andinteractions between individual elements on the Physical (Electrical)Layer of a DTC according to an embodiment of the invention;

FIG. 8A is a diagrammatic representation of a configuration, accordingto one embodiment, for effecting communication between an MCU device andan EMV device where the communication lines between the EMV externalcontacts plate are switched;

FIG. 8B is a diagrammatic representation of a configuration, accordingto one embodiment for effecting communication between an MCU device andan EMV device in which the data bus extending between the MCU device andthe EMV device is switched, whereas the data and control lines extendingfrom the EMV external contacts plate are connected directly to the EMVinternal contacts plate and the EMV device and are not switched;

FIG. 8C is a diagrammatic representation of an alternativeconfiguration, according to an embodiment, for effecting communicationbetween an MCU device and an EMV device in which selected control linesbetween the EMV external contact plate and the EMV device are switchedand similarly, only selected data and control lines between the MCUdevice and the EMV device are switched;

FIG. 8D is a diagrammatic representation of a further alternativeconfiguration, according to an embodiment, for effecting communicationbetween an MCU device and an EMV device including an external Vccdetection circuit which determines the switching of control linesbetween the EMV external contact plate and the EMV device and/orcorresponding control lines between the MCU device and the EMV device;

FIG. 8E is a diagrammatic representation of yet a further alternativeembodiment for effecting communication between an MCU device and an EMVdevice in which none of the data and/or control lines between the MCUdevice and the EMV device are switched and further, none of the dataand/or control lines between the EMV external contact plate and the EMVdevice are switched; and

FIG. 8F is a diagrammatic representation of an alternative embodiment inwhich the configuration for effecting communication between an MCUdevice and an EMV device relies upon communication between the MCUdevice and the EMV device by means of separate antennas connected to theMCU device and the EMV device respectively, thereby enablingcommunication between the MCU device and the EMV device without the MCUdevice requiring use of any of the data and/or signal lines connectedbetween the EMV external contacts plate and the EMV device.

DETAILED DESCRIPTION OF THE EMBODIMENT(S) OF THE INVENTION

FIG. 1 details the primary components of an apparatus (100) according toan embodiment of the invention, including a Digital Transaction Card(DTC) (108), a Data Assistance Device (DAD) in the form of a smartphone(106) and a Digital Transaction Device (102), which in this example is aPoint of Sale/Electronic Funds Transfer at Point of Sale (POS/EFTPOS)terminal (102). Such terminals (102) may be referred to herein asmerchant terminals, and may engage with the DTC (108) according to acontactless close proximity communication capability according toISO/IEC 14443 between a terminal transceiver (not shown) and a DTCtransceiver (114). Terminal (102) may also engage with a smartphonetransceiver (116) and communicate therewith in accordance with theISO/IEC 14443 Communications protocol. It is also possible for terminals(102) to engage by physical contact with the DTC (108), or with amagnetic stripe on the DTC (108). In the embodiment shown, the terminal(102) requires insertion of the DTC (108) into the terminal (102) toengage by physical contact. In the embodiment of FIG. 1, the smartphone(106) wirelessly engages with the DTC (108) by NFC, whereas the DTC(108) wirelessly engages with the terminal (102) by communicationsaccording to ISO/IEC 14443 which is a sub-set of the NFC Communicationsformat.

It will be understood that many types of smart devices, or computingdevices, such as smartphones (106), are unable to interact with manytypes of POS/EFTPOS terminals (102) and Automatic Teller Machines(ATMs). In order to complete a transaction with such terminals, it isnecessary to use a debit or credit card. However, debit or credit cardswill each have a single “personality”, or comprise the physicalembodiment of only a single digital transaction document. For example,presently, a physical transaction card can only have the personality ofa MasterCard or a Visa card, but cannot selectively and serially assumethe personality of both a MasterCard and a Visa card, at differenttimes.

In the embodiment shown in FIG. 1, the DTPU (104) on the DTC (108) is anEMV device (where EMV is an abbreviation for Europay, MasterCard, andVisa), or a device complying with one or more of the EMV Cospecifications, which has been adapted to allow expression of a numberof different personalities. Such current DTPUs or EMV devices mayinclude Read Only Memory (ROM), Random Access Memory (RAM), and/orElectrically Erasable Programmable Read Only Memory (EEPROM). The DTPU(104) may contain other kinds of memory, and the DTPU (104) may includea Central Processing Unit (CPU) for controlling operations of the DTPU(104). The DTPU CPU may work in cooperation with a crypto-coprocessorwhich handles the tasks of encrypting and decrypting data, thus freeingthe DTPU CPU to perform other processing tasks. Communications betweenthe DTPU (104) and electrodes (112) on the surface of the DTC (108) areeffected by a system Input/Output (system I/O) of the DTPU (104).

Similar to a standard EMV device, the DTPU (104) of the embodiment shownin FIG. 1 is located in a plastic credit card body using electrodes(112) for communicating externally. However, the DTPU (104) may alsocommunicate externally with terminals (102) using a wirelesstransceiver.

In an embodiment in which the operating firmware of an EMV device ismodified, the DTPU (104) EEPROM may be divided into two memory areas. Insome embodiments, the division could be by partition (or virtualpartition), by use of a suitable file structure, or by use of a suitabledirectory structure. In this example embodiment, part of the EEPROM isused as staging memory (staging area). During operation, the stagingmemory has at least one Logical Digital Transaction Document Packet(LDTDP) written into it from LDTDP storage memory. Another part of theEEPROM is used as the secure record memory (secure element). Duringoperation, the at least one LDTDP is taken from staging memory, andwritten into the secure element, which is accessed by the DTPU CPU whenthe DTPU is activated to read the secure element. When the DTPU CPUaccesses the LDTDP, the DTPU (104) is able to assume the personalityrepresented by the LDTDPs, such that the DTC (108) can be used fortransactions with that personality.

In other embodiments, instead of using a single EEPROM divided into twomemory areas (staging and secure record memory areas), there may beprovided two separate memory chips each containing one of a stagingmemory and a secure record memory. These memory devices (or chips) couldbe configured in the DTPU (104) to have no direct link, in order toincrease security, particularly for the secure record memory, whichshould only be directly accessible by certain designated elements in theDTPU (104), such as the DTPU CPU.

In the DTC (108), in accordance with an embodiment of the invention,there may be located an external DTC CPU different from, and additionalto, the DTPU CPU. The control of the DTPU (104) may be by control of theDTPU CPU. The external DTC CPU and the firmware associated therewith mayallow data (including LDTDPs) to be communicated to the DTPU (104)through the system I/O. The external DTC CPU and firmware can beoperated to instruct the DTPU CPU to copy data (for example, one or moreLDTDPs) into the staging memory. The DTC CPU can also be operated toinstruct the DTPU CPU to transfer the data in the staging memory to thesecure record memory.

The data containing the LDTDPs can be stored in LDTDP storage memory,either in the smartphone (106) or on the DTC (108) itself in a memoryseparate from the memories in the DTPU (104). The arrangement depictedin FIG. 1 allows LDTDPs to be stored in LDTDP storage memory, and to becopied from LDTDP storage memory to staging memory. Copying from LDTDPstorage memory to staging memory may be controlled by the external DTCCPU, which in turn controls operation of the DTPU CPU. The operation ofthe external DTC CPU may be controlled by the DAD (106), being operatedby a user via the user DAD user interface 110.

In another step of an example operation, the data containing the one ormore LDTDPs is loaded from staging memory into secure record memory ofthe DTPU (104).

In embodiments, a link is established between a smartphone (a DAD) (106)and a DTC (108), using strong encryption for the identification andtransfer of data therebetween. The link may be unique to each pairing ofa smartphone (106) with a DTC (108).

The external DTC processor (or DTC CPU) is typically activated onlyafter securely identifying itself to the linked smartphone. The DTCprocessor on the DTC (108) controls the reading and re-reading of theDTPU (104), and updating of the DTPU (104) to express new personalities.In some embodiments, the external DTC CPU may be activated by pressingan on/off switch on the DTC (108). In other embodiments, the DTC CPU isactivated (and powered) by the DAD (106).

In embodiments, after the smartphone (106) and DTC (108) are securelylinked, the smartphone (106) uploads correctly formatted data (forexample, an LDTDP) to the nominated secure storage area (for example,staging memory) by the external DTC CPU after meeting specific standardsand passing various checks for compliance, and then transmits aninstruction to the DTPU processor to do the following:

-   -   Check if the nominated storage area (staging memory) contains        data (an LDTDP) in a specified format;    -   If the data meets a specified standard and passes various        checks, the DTPU processor copies or moves the data to a        specified area (secure record memory) within the DTPU;    -   The processor then sends an instruction to the DTPU (104) to        read the data within the specified area (secure record memory)        and act according to the data contained within that area, which        may be stated as the DTPU (104) expressing the personality of        the particular document represented in the LDTDPs in the secure        record memory;    -   The DTPU processor may then be instructed to search for specific        headers and other data identifiers within a range of parameters        before acting on that data.

It will be understood by skilled readers that the DTPU (104) may be anEMV device constructed with an increased storage area, which isspecifically instructed to check and/or monitor a secure storage area(this may be referred to as secure record memory or secure element). TheEMV device may also accept commands from, for example, an externalprocessor resident within the DTC (108).

In embodiments, the external DTC processor only transfers data into thememory area(s) of the DTPU (104), and once inside this memory area, theDTPU processor is responsible for further copying, reading, writing,and/or processing of the data. However, in other embodiments, the datamay remain under the control of the external DTC processor, wherein theexternal DTC processor (CPU) may issue instructions to the DTPUprocessor (CPU) to operate to copy, read, write, and/or process thedata.

In another embodiment, the DTPU processor verifies data beforetransferring same to the secure location (secure record memory).Further, the DTPU processor after completing the check and verificationof data instructs the EMV device to load the data, or update itself.

In various embodiments, all memory storage (LDTDP storage memory,staging memory, and secure record memory) may be located on the EMVdevice. Alternatively, some memory storage could be located on a chipoutside the DTPU, but linked to the EMV device. The memory storage maybe file based, using data files (electronic files) located in aDirectory File (DF), with a root directory, or Master File (MF).

The firmware on the external DTC processor may be native firmware (usingmachine language), but could be interpreted code executed according toan interpreter based operating system, including Java card, MultOS, orBasicCard. Because both the external DTC CPU and the DTPU CPU provideinstructions, the external DTC CPU would benefit from having the samefirmware as the DTPU CPU, therefore allowing instructions to be providedusing the same format. In this regard, if and when updating firmware forthe external DTC CPU, it can be beneficial to also update firmware forthe DTPU CPU. In some embodiments, firmware for both the external DTCCPU and the DTPU CPU could be stored in the same location, accessible byboth CPUs, therefore requiring only updates to one firmware repository.However, a single source of firmware may have security implications.

FIG. 1 details a DTC (108) which may form a communication link via a DTCtransceiver (114) with a smartphone transceiver (116) of smartphone(106) to enable data transfer therebetween. In embodiments of theinvention where the digital transaction document in respect of which auser seeks to conduct a transaction, the user may operate the userinterface (110) of the smartphone (106) to select a particular digitaldocument and activate that digital document in the DTC (108). Once theDTC (108) adopts the required personality and assumes thecharacteristics of the digital transaction document selected by the useroperating their smartphone (106), the DTC (108) may then be used toconduct transactions with the DTC (108). In this regard, the DTC (108)operates with all of the characteristics of the selected digitaltransaction document which once activated as the document to beinstalled as the document to which the DTC pertains, the documentbecomes the personality of the DTC. In other words, once a DTC becomesthe physical embodiment of a document, the document transitions to a“personality” of the DTC.

In particular, the DTC (108) with the selected personality of choice fora digital transaction document, may then be used to conduct transactionsaccording to the existing infrastructure of a digital paymenttransaction network including Automatic Teller Machines (not shown),and/or a merchant terminal (102) as shown in FIG. 1 to effect a range oftransactions.

In the case of using the DTC (108) with a selected digital transactiondocument as its personality, the merchant terminal (102) with which theDTC (108) communicates may be effected by use of any of the existingcommunication means between DTCs and merchant terminals and in FIG. 1.The example illustrated includes a transaction effected between the DTC(108) and a merchant terminal (102) by physical contact between the DTC(108) and the merchant terminal (102) which generally includes physicalcontact between an external contact plate (112) of a payment deviceincorporated in the DTC (108) and electrodes (not shown) resident withinthe merchant terminal (102).

Further examples of conducting a transaction between a DTC (108) and amerchant terminal (102) include the use of contactless close proximitycommunication capabilities of the DTC (108) and the merchant terminal(102) and in instances where the DTC (108) includes a magnetic stripe,using a magnetic stripe reader of the terminal (102) and the DTC (108)to effect the transaction.

The embodiment in FIG. 1 has been described above in terms of anembodiment including a firmware modified EMV device. Of course, skilledreaders will appreciate that the same, or similar, improvements to thefunctioning of a DTC (108) can be achieved with an embodiment includinga software enhanced EMV device which has the advantage of reducedcomplexity regarding any requirement to certify the device in view ofany software enhancements.

Similarly, the embodiments described in FIGS. 2A, 2B and FIGS. 4A to 4Dcould be implemented with arrangements involving either a firmwaremodified EMV device or a software enhanced EMV device.

With reference to FIG. 2A, a DTC in the form of a physical card (200)with associated DAD user interface (202) is diagrammatically illustratedstepping through a process of selecting a different personality for theDTC (200).

In the embodiment of FIG. 2A, the DTC (200) does not have a specificpersonality at the commencement of the process of selecting apersonality. A user may operate a smartphone (204) and communicate withthe DTC (200) in accordance with a contactless close proximitycommunication protocol in order to select the personality required ofthe DTC (200). In the particular example of FIG. 2A, the smartphone(204) has executed software to present available card personalities to auser who has selected a VISA card as the preferred personality of theDTC (200). In an embodiment, it may be necessary for the user to providebiometric authentication such as a fingerprint in order to operate thesmartphone (204) to select a personality for the DTC (200).

Once the smartphone (204) communicates the user's selection of a VISAcard as the personality that should be adopted by the DTC (200), therelevant selection and/or data is transferred from the smartphone (204)to the DTC (200) and upon receipt of the selection and/or datarepresenting the LDTDP of a VISA card, the DTC adopts the personality ofthe VISA card (206). At a subsequent point in time, the user may preferto change the personality of the DTC to a MasterCard and may operatesoftware on their smartphone to select a MasterCard personality for thepurpose of effecting a personality change in the DTC. With reference toFIG. 2A, the smartphone (204) has been operated to select a MasterCardpersonality and upon communicating the relevant selection and/or LDTDPdata to the DTC (200), the DTC adopts a MasterCard personality andsubsequent to which, the DTC (200) will operate as the consumersMasterCard (208).

Ultimately, once a consumer has completed conducting transactions withtheir DTC, they may prefer to render the DTC with a Null personality andwith reference to FIG. 2A, the smartphone (204) is operated to identifythat the consumer prefers to lock their DTC by imparting a Nullpersonality to the DTC. Upon communication of the user's request, thesmartphone (204) causes the DTC (200) to adopt a Null personality (200).

In the embodiment of FIG. 2A, the DTC (200, 206, 208) is a modified DTPUexecuting software that has been modified to allow/enable the DTC toadopt different personalities including a Null personality in accordancewith data instructions transferred to the DTC by the DAD (204).

The communication between the DAD and DTC may be effected by the DADprocessor communicating with a DTC external processor via respectivetransceivers (shown in FIG. 1 as smartphone transceiver (116) and DTCtransceiver (114) respectively) and wherein the DTC external processorhaving received instructions and/or from the DAD, co-operativelycommunicates with the EMV device to cause the EMV device to adopt arequired personality in accordance with the instructions and/or receivedby the DTC from the DAD.

With reference to FIG. 2B, the same steps depicted in FIG. 2A areillustrated in FIG. 2B regarding the change of personality of a DigitalTransaction Card. The reader will note that the DTC in FIG. 2B is a DTCwith a Null personality (210) including a user interface, which isdescribed in more detail below, particularly with reference to FIG. 3D.In the instance of the embodiment depicted in FIG. 2B, the request tochange the personality of the DTC (210) is effected by the DTC userinterface as compared with the DAD user interface (refer FIG. 2A). Asfor the DTC (200) in FIG. 2A, the Null personality DTC (210) in FIG. 2Btransitions to a VISA card (206) by the user operating the userinterface on the Null personality DTC (210) which includes scroll andenter keys and a display on the DTC.

When seeking to change the personality from a VISA card (206) to aMasterCard (208), the user operates the scroll keys of DTC (206 a)observing the display which displays available personalitiessequentially as the scroll keys are repeatedly depressed. Once aMasterCard personality is displayed, the user may depress the enter keyand the DTC personality is altered accordingly. The DTC (208) can bechanged to a Null personality again by the user operating the userinterface of DTC (208 a) to display and select a Null personality andeffect same.

FIG. 3 shows components of a digital transaction system (300), which isan example of a system using a battery. The battery for which analysisand usage monitoring is required is located on a Digital TransactionCard (DTC) (350). The system (300) also includes a Data AssistanceDevice (DAD), in this embodiment, a smartphone (301). The smartphone(301) and the DTC (350) may be linked with each other to form a securecommunication channel between the two.

The DTC (350) has a battery (351) and a DTPU (357), where the latter maybe an EMV chip or a chip complying with one or more of the EMV Cospecifications. The DTC also has a processor (352), which is external tothe processing unit in the DTPU, and the external processor (352) may beoperating its own firmware or own version of firmware for control of theDTC operations outside of the DTPU (357). The DTC may also include othercomponents such as a transceiver (360) (this may be an NFC transceiveror a Bluetooth™ transceiver, or some other transceiver infrastructureand protocol.) The DTC also includes an inductive coil which is used forNFC type communications. The DTC may also include a display (354) fordisplaying simple alphanumeric information, such as card numbers (orunique IDs for other types of digital transaction documents), errormessages and the like.

Additional elements are also depicted in DTC (350) including anelectrodes (or external contacts) (358) and display driver (355).

The DAD (smartphone) (301) includes a user interface (302), which may bea touch screen operable with soft buttons, and may include physicalbuttons elsewhere on the device (301).

The digital transaction system (300) is operational to perform financialdigital transactions in cooperation with a digital transaction device,such as a Point Of Sale/Electronic Funds Transfer at Point Of Sale(POS/EFTPOS) terminal, an Automatic Teller Machine (ATM), or anothertype of transaction terminal. The digital transaction system may also beoperational to perform non-financial transactions with other types ofdigital transaction device, for example, age identification transactionswith a digital transaction device adapted to read age identificationcards. It will be appreciated that the DTC, in coordination with thesmartphone is able to take on the “personality” of a number of digitaltransaction documents, including credit cards, debit cards, passports,and age identity cards.

It will be appreciated that to facilitate the function for change ofpersonality, along with other functions, the DTC requires a powersource. As mentioned, the DTC (350) includes a battery (352) (which maybe a rechargeable or non-rechargeable battery). In the example, the DTChas a display (356), however, the display is not suitable for displayingrelatively complex information about the battery status and batteryusage. Instead, the DTC operates with the smartphone, and the smartphoneis suitable for displaying the battery status and/or battery usageinformation.

The DTC further includes a Digital Transaction Processing Unit (DTPU)(358), which may be an EMV chip (where EMV is an abbreviation forEuropay, MasterCard, and Visa) or a chip complying with one or more ofthe EMV Co specifications. The DTC also has a processor (354), which isexternal to the processing unit in the DTPU, and the external processor(354) may be operating its own firmware or own version of firmware forcontrol of the DTC operations outside of the DTPU (358). The DTC mayalso include other components such as a transceiver (360) (this may be aNear Field Communication (NFC) transceiver or a Bluetooth™ transceiver,or some other transceiver infrastructure protocol. The DTC also includesan inductive coil (362), which may be used for NFC type communications.The DTC may also include a display (356) for displaying simplealphanumeric information, such as card numbers, error messages and thelike—as mentioned above, the display is not suitable for showing morecomplex information, such as battery usage, which may include chartsindicating percentages and other detailed information.

All the DTC components consume power (or energy) while functioning, andrequire a power source, namely battery (352). A user will benefit fromknowing the likely effective operational life expectancy of the battery(including likely remaining charge for a rechargeable andnon-rechargeable battery, and likely remaining number of recharge cyclesfor a rechargeable battery). If the DTC were to cease functioning due tobattery discharge, the user of the DTC may be inconvenienced.Accordingly, the DTC is adapted to record a number of details regardingthe usage of the battery into its on-board memory, whether that usage isauthorized (legitimate) usage or unauthorized (illegitimate) usage. Itwill be appreciated that both legitimate and illegitimate usage of theDTC contribute to energy discharge, and shortening the expected life ofthe battery.

The usage of the DTC, in this embodiment, is recorded for each componentas an event. The event recordal includes identification of the componentof the DTC, identification of the event type operating on the component,along with duration of the event. Each event (or each event type foreach component) has an associated nominal power usage amount, which ispredetermined and recorded into a database or other data repository foraccess when calculating battery usage. The system is operational to usethe recorded event information and the predetermined power usage amountto calculate the battery usage for the event, and then to calculate thetotal battery usage.

It will be understood that the system (300) can calculate and recordtotal battery usage for a non-rechargeable battery, and is thus enabledto indicate likely remaining life of the non-rechargeable battery.However, in this embodiment the DTC battery (352) is a rechargeablebattery, and the system (300) is operable to record total battery usageso as to indicate, and is thus enabled to indicate likely remainingcharge life for a recharge cycle. However, the system is also operableto record a grand total battery usage, and is thus enabled to indicatelikely remaining life of the rechargeable battery (or the number ofrecharge cycles remaining before the battery is likely to stop operatingor to start operating at below acceptable performance).

In this embodiment, the DTC (350) records the usage (events, eventtypes, components, and durations) into its memory. The DTC andsmartphone (301) are able to link with each other for secure datatransfer therebetween, such that the usage data is transferred to thesmartphone. The usage data transferred to the smartphone can be deletedfrom the DTC (350), so that the DTC can record next usage data into itsmemory. It will be appreciated that the DTC may have limited memorycapacity.

In the embodiment described, the smartphone includes a softwareapplication, which operates with the DTCs collected usage data, andobtains corresponding associated nominal power usage amounts for theusage data.

In an example scenario, the usage data may include a record indicatingthat the DTPU (358) was used for a transaction event (for example, apayment transaction with a digital transaction device, such as anPOS/EFTPOS terminal), and the transaction event had a duration of 340milliseconds. The corresponding associated nominal power usage amountfor a transaction event using the DTPU is predetermined to be 5milliwatts. The application on the smartphone will thus calculate theenergy usage to be 0.000000472 Watthours. This usage amount, along withother usage amounts for other events, is added to a total usage recordedon the smartphone. Alternatively, the total usage can be recorded ontothe DTC, or could be uploaded to another entity in the internet cloud.Further, this usage amount, along with other usage amounts for otherevents, is added to a nominal grand total usage also recorded on thesmartphone (or elsewhere).

The smartphone (301) is able to indicate to a user the amount of chargelikely left on the battery for the particular charge cycle by comparingthe total usage with an expected available total usage. The expectedavailable total usage may be specified, for example, by the batterymanufacturer, and can be recorded into a database or other datarepository accessible by the smartphone. In some embodiments, theexpected amount of charge left for each recharge cycle may diminish asthe battery ages. The aging could be determined by a recorded date ofinception for the battery, or by the grand total usage.

The smartphone (301) is also able to indicate to a user the remaininglife of the battery (the total number of expected recharge cyclesremaining for the battery) by comparing the grand total usage (the usageof the battery across all previous recharge cycles and the presentrecharge cycle) with an expected available grand total usage. Again, theexpected available grand total usage may be specified, for example, bythe battery manufacturer, and can be recorded into a database or otherdata repository accessible by the smartphone. In an alternativeembodiment, rather than the DTC recording the event duration for eachevent, the DTC can record the event solely by identifying the componentused and the event type. Correspondingly, the predetermined associatednominal usage amounts are energy usage amounts (predetermined expectedpower over a predetermined expected time period for each event type),rather than power usage amounts. In such an embodiment, the calculationincludes adding all the associated energy usage amounts corresponding tothe recorded events (event type and component) to determine a totalusage amount.

As shown in FIG. 3, the DTC external processor (354) is capable ofrecording information on battery usage, with an example record beingshown in table (362). Table (362) can include records of events andrecords of components, which may include an “on event” (380), “displayevent” or “display operation” (381), a “set NFC” event (382), a “readNFC” event (383), a “set EMV” event (384), a “read EMV” event (385), and“processor operation” event (386), an “encryption” event (387), a“transaction” event (388), and may have capacity to record other kindsof “miscellaneous” events (389).

Column headings in (362) show example information which can be recordedfor the events or operations of components, including: whether an eventor operation of a component is “authorised” (364), the “start_time”(365), the “finish_time” (366), the “time_length” (367) (differencebetween the “finish time” (366) and “start time” (365), otherwisereferred to as the duration of an event, the “voltage” used from thepower source (368), another “miscellaneous” value (369), the“GPS_location” (370), the time of unauthorized usage (371), the averagetime of unauthorized usage (372), the total time of unauthorised usage(373), “remaining_time” (374), “start_voltage” (375), “cur_voltage” 376and “tot_value” (377).

An application executing on the smartphone (301) may upload the batterystatus, which may be derived from the record (362) of battery usage.This may be displayed in screen section (304). The smartphone (301) canalso display in another area of the screen (306), the battery liferemaining as a percentage. The smartphone (301) can also display inscreen area (306) whether there has been any unauthorised usage, forexample one unauthorised NFC usage.

Further, the user of the smartphone may optionally prefer to send dataabout battery usage to a third party. The data (363) may include batterytime used, battery time remaining, voltage, battery usage details,transaction locations, transactions details, unauthorised usage andunauthorised usage details. The information (363) can be sent to, forexample, an issuing financial institution (395), being the institutionthat issued the DTC, or the institution that issued the digitaltransaction document running on the DTC.

With reference to FIG. 4A, a DTC in the form of a wearable device (400)is illustrated along with a DAD in the form of a Smartphone (402) and amerchant terminal (404). In this particular embodiment, the wearabledevice (400) is a watch which also provides the function of displayingthe current time and any other functions that are available according tothe wearable device (400). Increasingly, wearable devices are beingadopted by consumers to combine the functions of many individual itemsthereby reducing the complexity of conducting transactions since, oncethe functionality of a DTC is incorporated into a wearable device (400),it is no longer necessary to carry a separate DTC. Wearing the wearabledevice (400) enables the user to conduct transactions with the devicethat they would ordinarily wear. In the instance of FIG. 4A, thewearable device (400) is illustrated communicating with the smartphone(402) and a merchant terminal (404) via contactless close proximitycommunication. Of course, despite all three devices being illustrated inclose proximity, skilled readers will understand that it is notnecessary for the wearable device (400) to be in contactless closeproximity communication with both a smartphone (402) and a merchantterminal (404) simultaneously and the communication between respectivedevices may occur separately at different times.

With reference to FIG. 4B, an alternative wearable device in the form ofa ring (406) is detailed in contactless close proximity communicationwith a DAD in the form of a smartphone (402) and a merchant terminal(404). Once again, in the illustration in FIG. 4B, communication betweenthe smartphone (402), the wearable device in the form of a ring (406)and a merchant terminal (404) all occur using contactless closeproximity communication.

With reference to FIG. 4C, yet another embodiment is illustrated inwhich the DTC is provided in the form of a smartphone case (408). Inthis particular embodiment, a DAD in the form of a smartphone (402)communicates with a DTC in the form of smartphone case (408) which inturn communicates with a merchant terminal (404). All communicationsillustrated in FIG. 4C occur in accordance with contactless closeproximity communication according to ISO/IEC 14443 and in thisparticular embodiment, rather than a wearable device, the DTC takes theform of another convenient device, namely, a smartphone case (408) sinceusers regularly purchase cases for their smartphones in order to protecttheir smartphone from damage. Of course, in the embodiment of FIG. 4C,if a consumer were to user a DTC in the form of a smartphone case (408),and attach the case (408) to the smartphone (402), then the DAD in theform of the smartphone (402) and the DTC in the form of a smartphonecase (408) are in the consumers possession at the same time.

The reader will appreciate that the DTC may be configured in a number ofdifferent ways, and there is a range of possible DTC embodiments from aDTC having minimal (or limited) functionality/connectivity but will beless expensive to produce and less prone to failure, to a DTC havingmaximum functionality and including features that assist userinteraction and will therefore be considered more “user friendly” butwill be more expensive to produce and will be more likely prone tofailure. FIG. 3D provides diagrammatic representations of four DTCswhich have a credit card profile whereby each includes an EMV device(410) and an optional printed identification (412), which in theembodiment shown is the card owner's name, and whose features offunctionality/connectivity represent significant differences in userexperience with respect to digital transactions.

For example, the uppermost DTC (414) that is depicted in FIG. 4Drepresents a card having minimal functionality/connectivity and includesan EMV device (410) that is either firmware-modified software-enhancedto enable NFC wireless connectivity between the EMV device and a DAD(402) and to change the personality of the DTC (414), but excludes anexternal DTC processor (referred to as an MCU), Bluetooth connectivityand any form of display or scroll/enter keys. In one particularembodiment, DTC (414) that is configured with minimalfunctionality/connectivity can be issued to a user such that the EMVdevice (410) has pre-loaded multiple personalities. More commonly, afterthe DTC (414) is delivered to the user, the DAD (402) may be used totransfer one of multiple personalities onto the EMV device (410) or anumber of personalities for simultaneous storage by the EMV device(410).

The second DTC (416) that is depicted also represents a card havingminimal functionality/connectivity including an EMV device (410) that iseither firmware-modified or software enhanced to enable wirelessconnectivity between the EMV device and a DAD (402), such as Bluetoothand/or NFC, to change the personality of the DTC (416). The DTC (416)also includes an MCU (not shown in FIG. 4D). A DTC (416) that isconfigured with relatively minimal functionality/connectivity butincluding an MCU can be issued to a user with the EMV device (410)having access to data performing to multiple personalities.Alternatively, after the DTC (416) is delivered to the user, the DAD(402) may be used to transfer one of multiple personalities onto the EMVdevice (410) or a number of personalities for simultaneous storage bythe EMV device (410).

The third DTC (418) that is depicted in FIG. 4D represents a mediumfunctionality/connectivity card including an EMV device (410) that iseither firmware-modified or software enhanced to enable wirelessconnectivity between the EMV device (410) and a DAD (402), such asBluetooth and/or NFC, and to change the personality of the DTC (418).The DTC (418) also includes a display (420) which may be in the form ofa simplified 4-digit alphanumeric interface for displaying information,including but not limited to, the selected personality loaded (orpreviously stored) on the card, a unique ID or abbreviation of theselected personality, an expiry date for the document, a temporary PINnumber, a PAN number or part thereof, and/or a name of the card owner. ADTC (418) that is configured with mid-range functionality/connectivitycan be issued to a user such that the EMV device (410) has access todata pertaining to multiple personalities. Alternatively, after the DTC(418) is delivered to the user, the DAD (402) may be used to transferone of multiple personalities onto the EMV device (410), or a number ofpersonalities for simultaneous storage by the EMV device (410).

The fourth DTC (422) that is depicted in FIG. 4D represents a cardhaving a high level of functionality/connectivity and includes an EMVdevice (410) that is either firmware-modified or software-enhanced toenable NFC or Bluetooth wireless connectivity between the EMV device(410) and a DAD (402) and to transfer multiple personalities onto theEMV device (410) after delivery of the card. The DTC (422) also includesa more comprehensive display (424) and scroll/enter keys (426) whichenable user input, including input effecting selection of a storedpersonality. The skilled addressee will appreciate that the inclusion ofa user interface on the card enables the DTC (422) to be used even whena DAD (402) such as a user's smartphone is not present, for example, ifthe DAD is not being carried by the user or has a discharged battery.

As previously described, whilst it is possible to implement embodimentswith hardware and firmware that is adapted to enable a DTC comprising aDTPU to adopt one of many available personalities, it is preferable toachieve the results with an existing, certified DTPU, such as a devicecertified in accordance with the EMVCo specifications, without requiringany alteration to the DTPU or any essential operating firmware. As willbe appreciated by skilled readers, avoiding the requirement to certify anewly developed DTPU has the benefit of avoiding a substantial costassociated with the certification process and avoids the substantialdelay also associated with such a process.

Devices such as EMV devices operating with an operating system such asthe MULTOS or JavaCard systems allow the secure execution of applicationsoftware that is installed within the EMV subsystem. EMV subsystems areconsidered sufficiently secure to allow third party software to beinstalled and operated within the EMV subsystem subsequent to reissuanceof an EMV device since the operating system will prevent anyinappropriate alteration of the EMV device secure memory.

Accordingly, by installing application software in the EMV system thatoperates to receive commands that are already available and definedaccording to the current EMV subsystem, additional functionality beyondthat provided by standard DTCs can be achieved. In the embodiment(s)described in FIG. 4 onwards, the DTPU is implemented in the form of asoftware-enhanced EMV device.

Also depicted in FIGS. 5A and 5B, is a Global Platform API (514) and aGlobal Platform Card Manager (516). The Global Platform Standard (GPS)is a standard that enables an open and interoperable infrastructure forsmart cards, devices and systems that simplifies development, deploymentand management of computer instruction code and the functionalityprovided by same. The GPS specification has been adopted by most bankinginstitutions for loading of cryptographic data onto smart cards. Thestandard establishes mechanisms and policies that enable secure channelcommunication with credentials. Further, the specification represents astandard for managing the infrastructure of a smart card. Management, inthis regard, includes installation, removal of applications andadditional management tasks to be effected for a card. The primaryauthority for management of card data is the card issuer who generallyhas full control of the card contents but may grant other institutionsaccess to administer their own software applications. Management isgenerally achieved by applying cryptographic protocols whichauthenticate and encipher the relevant processes.

The Global Platform API (514) provides an interface to the functionalityprovided by the Global Platform Standard and in the embodiment depictedin FIGS. 5A and 5B, the Global Platform API is used to load, configureand select different card personalities for the DTC (500) to effectdigital transactions in accordance with that particular selectedpersonality. The Global Platform API (514) is defined as part of theGlobal Platform Card specification. The Global Platform Card Manager(516) is the central controlling entity in the DTC (500). It includesthree separate entities, namely, the Global Platform environment, theissuer's security domain and the card holder verification methodservices.

The DTC (500) also includes a DTC external processor (524) which effectsfunctions on the DTC (500). In particular, the DTC external processor(524) depicted as a microcontroller unit (MCU), which communicates withthe EMV device and this communication arrangement enables the DTCexternal processor (524), in accordance with commands received by theDAD (526), to update the digital transaction document personalities andthe applications residing within the EMV device.

The EMV device operating system (528) is hardware specific firmware thatprovides the basic functionality for the EMV device such as secureaccess to on-card memory storage, authentication and encryption. Theoperating system (528) includes a sequence of instruction code thatresides in non-volatile memory in the EMV device.

With reference to FIGS. 5A and 5B, a DTC (500) is depicted according totwo embodiments and the individual components of the EMV device withinthe DTC (500) have been expanded and appear above the DTC (500).

The EMV device of the DTC (500) in FIG. 5A includes a single-personalityapplet (501) whilst the EMV device of the DTC (500) in FIG. 5B includesa number of applets (502, 504, 506, 508, 510 and 512).

In the example of FIG. 5A, the applet (501) contains data and/orinstructions defining a single digital transaction document(personality) and is an applet that has been received and installed bythe EMV device. A plurality of single-personality applets may be storedeither in a personality section (secure holding position) on the EMVdevice that may be created at the time of initialisation of the EMVdevice, or in a secure location of an external processor (524)associated with the DTC (500) which is depicted in some Figures as amicrocontroller unit (MCU). In the example depicted in FIG. 5A, thesingle-personality applet (501) that has been selected and installedonto the EMV device defines a Visa Card personality (501). By ensuringthat there is only one stored applet on the EMV device, only onepersonality is available to be adopted by the DTC (500) and read by adigital network transaction device. Accordingly, by assuming thatapplets safely define a single personality, there is no requirement toaccommodate a plurality of concurrently stored applets on the EMVdevice.

When multiple single-personality applets are stored in the MCU, GlobalPlatform Standard (GPS) command(s) are sent to the EMV device, forexample from a DAD (526) or the MCU, to install the relevantsingle-personality applet (501) onto the EMV device along with theappropriate command(s) to overwrite any previously installed applet thuschanging the personality of the DTC to the personality associated withthe applet (501). In this embodiment, the applet could be stored in theMCU secure memory, i.e. secured by hardware (secure element) or securedby software (encryption). The EMV contact plate (not shown in FIG. 5)shall also be secured during any transaction between the EMV device andthe MCU to ensure third parties are unable to “listen in” (man in themiddle attacks) or inject commands.

When the multiple single-personality applets are stored in a personalitysection of the EMV device, GPS command(s) are sent to the EMV device,for example from a DAD (526) or the MCU, to transfer the relevantsingle-personality applet (501) from the secure element of the EMVdevice and install same thus effecting change to the personality of theDTC to the personality associated with the installed applet (501). Inyet another embodiment, the multiple single-personality applets arestored in a DAD (526) and individual applets along with commands aretransferred to the MCU (524) of the DTC for subsequent transmission tothe EMV device.

The commands sent from the DTC external processor to the EMV device maybe a set of commands that obscure the GPS commands such as “make card 2primary”, whereby the external DTC processor sends “make card 2 primary”to the EMV device, and the EMV device executes the command by decodingthe command and obtaining the GPS commands that will have the effect ofmaking the DTC adopt the personality of card 2.

Each single-personality applet (501) that is stored for subsequentselection and transfer to the EMV device has an associated encryptionkey (513) used to decrypt the contents of the applet defining theindividual personality thus allowing access and/or amendment toparameters pertaining to the individual personality. The function ofkeys is described in more detail below with respect to the embodiment ofFIG. 5B.

In the embodiment of FIG. 5A, in order to change the DTC personality,the Applet that contains the personality in the EMV device may bereplaced with a newly selected Applet for installation (overwriting theexisting Applet). Alternatively, the Applet that contains the activepersonality may be deleted and a newly selected Applet installed on theEMV device such that the personality contained in the newly selectedApplet will become the personality of the DTC.

If there is a preference to concurrently store applets containing one ormore personalities in the EMV device, a single applet of the pluralityof applets will need to be activated, or made primary, in order toensure that only one particular personality defined by an applet is readby a network digital transaction device. The reader will appreciate thatFIG. 5B depicts an EMV device that concurrently stores a plurality ofmultiple-personality applets (504, 506, 508, 510 and 512) in the EMVdevice of FIG. 5B.

In the example of FIG. 5B, the applets (504, 506, 508, 510 and 512) maycontain data defining one or more digital transaction documents, forexample, as depicted in FIG. 5B, there is an applet defining aMasterCard account (504), an applet defining two “other cardpersonalities” (506), an applet defining a loyalty card personality(508), an applet defining two separate Visa card personalities (510) andavailable space for a further applet that may define one or moreadditional personalities (512). The applet (502) is a system appletwhich is installed prior to issuance of the DTC. In the embodiment ofFIG. 5B, the system applet is a modified Payment Proximity SystemEnvironment (PPSE) applet which is installed prior to issuance of theEMV device by an authorised issuing entity. The PPSE applet determinesthe system environment that the EMV device operates within and anenhanced version of the PPSE applet is installed at the time of issuanceof the DTC that allows the EMV device to store more than one personalityat a time.

All of the applets (502, 504, 506, 508 and 510) reside within the securememory of the EMV device of the DTC (500) and in the embodiment depictedin FIG. 5B, the applets are implemented with Java code and contain thenecessary data and/or Java code instructions to define the one or morepersonalities for a particular payment Card Association Scheme.

In the embodiment of FIG. 5B, because the applets containing multiplepersonalities are stored concurrently on the EMV device, the EMV deviceof the DTC (500) also contains a “secure vault” (530) of cryptographickeys wherein each key is specific to each applet. The keys (530 a to 530e) are used to decrypt the contents of individual personalities withinan applet to access and/or amend parameters pertaining to the individualpersonality. The installation and storage of multiple appletssimultaneously on an EMV device causes the potential for a digitaltransaction device to adopt a personality other than the intendedpersonality of the DTC at any one time. Accordingly, in an embodiment,operational parameters of the multiple personalities are accessed andamended to ensure that only a single personality can be recognised bytransaction devices. Once the data pertaining to an individualpersonality stored in an applet is decrypted, it is possible to amendparameters such as the order of the personality within the EMV device,whether the personality is active or inactive, whether the personalityis primary or secondary, or any of the operational parameters thataffect the processing of a digital transaction such as expiry date, CVV,CVV2 and/or the PAN of the personality. The actions available once apersonality is decrypted with its associated key (530 a to 630 e),comprise full administration rights to effect a change to anyoperational parameter.

In an embodiment, two or more sets of keys may be jointly issued to theDTC for each personality, including for example a first set of keys (530a to 530 e) as shown in FIG. 5, for which full administration rights areavailable, and a second (or subset) of keys (not shown) for whichlimited administration rights are available. In an embodiment, thelimited administration rights available in respect of the second set (orsubset) of keys only allow amendment to the status of the personalityand amendment of a restricted set of operational parameters that areused during a digital transaction. The status of a personality includesthe order of the personality within the EMV device, whether thepersonality is active or inactive, whether the personality is primary orsecondary or any other parameter that is not used during a transaction.

The second set of limited administration keys (not shown) may be storedin the microcontroller unit (MCU) shown in FIGS. 6A, 6B, 7A, 7B and 8Ato 8F and described further below, or stored within the EMV device, suchas in one or more of the available spaces for an applet (512) depictedin FIG. 5B. An applet which stores the second set of keys is referred toherein as a Key Management Applet, and such an applet may be installedat the time of initialization of the Digital Transaction Card (DTC). Itis possible to store the limited administration keys within anotherdevice such as the DAD, however, any transfer of the limitedadministration keys to the EMV device would necessarily require thetransmission to be within a secure session.

With reference to FIGS. 8A to 8F, if keys are stored in the MCU (802), acontact plate associated with the EMV device, such as the externalcontact plate (804), and described further below, must be isolated sothat no-one can “listen in” (man in the middle attacks) when commandsare sent from the MCU (802) to the EMV device to monitor thecommunications, or to inject commands to alter the intended purpose ofthe transmitted commands.

Referring again to FIG. 5B, if the subset of limited administration keysare stored within the EMV device, such as a Key Management Applet inavailable space (512), the MCU to EMV security requirements may bereduced since commands from the MCU to the EMV device are protected bythe encapsulation of the DTC and as such, may be encoded (for example,make card 3 primary), and any Global platform commands used to effect anew personality remain internal within the EMV device. For example, ifthe MCU (524) contains a known numbering of personalities and sends acommand “make card 3 primary”, the EMV device can issue commandsinternally to effect the required action, including Global Platformcommands, to (1) make all cards inactive, (2) change the order of cardsto make card 3 primary, and/or (3) make card 3 active. For example, ifthere are six possible personalities stored within the EMV device, sixsets of commands may be issued to the relevant applet(s) that store datadefining the personalities to deactivate and activate personalities asrequired.

In an embodiment where the MCU to EMV link is secure, encrypted commandsare issued from the MCU to the EMV device but continue to invokemultiple Global Platform commands within the EMV device once the commandfrom the MCU is decrypted by the EMV device. This arrangement reducesthe quantity and complexity of encrypting and decrypting tasks to effectfunctions, which in turn, also reduces the overall power usage of theDTC and the time required to effect an action such as a request tochange the personality of the DTC.

In this regard, the MCU sends formatted messages to the System I/O ofthe EMV device and the Operating System and Java Runtime Environmentdirect the message to the appropriate applet. In this embodiment, theMCU emulates an EFTPOS and/or ATM network transaction terminalinternally on the DTC to effect communications confirming with commandsrecognised by the EMC device. Whilst the EMV device will receive andexecute recognised GPS commands, there is no single command that willensure that the correct personality is recognised by all networktransaction devices. In this regard, network terminals software caninterpret the personality stored on a physical card containing multiplepersonalities in different ways and may not always adopt the personalitymarked with the “primary” status. Accordingly, to ensure that a terminalproperly interprets and adopts only one of a number of personalitiesstored in the EMV device, only the desired personality should be markedas active and primary, all other personalities should have a status of“inactive”. Therefore, according to this embodiment, a number of GPScommands that are usually only used by an entity authorised to issuecards are issued to the EMV device to amend the status of each and everypersonality stored on the EMV device to ensure that the user selectedpersonality is recognised by any network terminal device in which theDTC may be used to effect a transaction.

FIG. 6A depicts a DTC subdivided into four separate layers, namely,commands (600), protocols (702), a Message Exchange Layer (604) and aphysical (electrical) layer (606). A mobile device (608) is alsoillustrated in FIG. 6A that communicates data and commands to the DTCvia a wireless protocol such as NFC or Bluetooth where those commandsand data are received by a transceiver (609). The transceiver (609)converts wireless signals transmitted from the mobile device (608) tosignals for reception by a communications module (610) embodied withinan Application Specific Integrated Circuit (ASIC). The communicationsmodule (610) subsequently transfers commands and data decoded from thetransmission of the mobile device (608) to the MCU (612) and interpretsthose commands and data. In an embodiment, the proprietary commandstransmitted from the mobile device (608) to the DTC by way of thetransceiver (609) and ultimately passed through to the MCU (612), areencrypted to protect the data and security of the DTC.

According to the protocol layer (602), the MCU (612) communicatesaccording to established protocols with the EMV device (614). In theembodiment of FIG. 6A, the MCU (612) uses a subset of the GlobalPlatform Standard commands that are usually only used by authorisedentities who issue credit cards with EMV devices. The subset of commandsis issued to the EMV device (614) as required according to the functionrequested by the mobile device (608). Application Protocol Data Units(APDUs) are used to communicate with the EMV device (614) and the APDU'sare also defined in the Global Platform Standard. In order to effect achange of card personality of the DTC, the MCU (612) communicates withthe EMV device (614) using the subset Global Platform Standard.

With reference to the message exchange layer (604), this layercommunicates messages between either a merchant terminal and the EMVdevice (614) or the MCU (612) and the EMV device (614). The messages forthis communication are APDUs. There are two primary categories forAPDUs, namely, command APDUs and response APDUs. Effectively, APDUcommands are the messaging protocol for communicating with an EMV device(614). The message exchange layer (604) also depicts the externalcontacts (616) of an EMV device (614). Further, the message exchangelayer (604) also depicts an arbitration device (618) which arbitratescommunication between the MCU (612) and the EMV device (614) oralternatively, communication that may occur between the EMV contacts(616) and the EMV device (614). As will be appreciated by skilledreaders, communication between the EMV device contacts (616) and the EMVdevice (614) will occur when the DTC is used in a merchant terminal a“dipping mode” wherein the DTC is inserted into the merchant terminaland contacts within the merchant terminal directly engage with the EMVcontacts (616). In this instance, communication between the EMV contacts(616) and the EMV device (614) must be effected without any interferencein the communication attempted by another device such as the MCU (612).However, in instances where communication between the MCU (612) and theEMV device (614) is required, the arbitration device (618) effectivelydisconnects the communication path between the EMV contacts (616) andthe EMV device (614) such that communication may be effected between theMCU (612) and the EMV device (614) without interference from any devicemaking contact with the EMV contacts (616). As depicted in FIG. 6A,communication between the MCU (612) and the EMV contacts (616) and theEMV device (614) is effected by APDUs in the embodiment of FIG. 6A. AnAPDU contains a mandatory four byte header defining the command and fromzero to sixty four kb of data. A response APDU may be sent by the EMVdevice (614) back to a merchant terminal or the MCU (612) and containsfrom zero to 64 kilobytes of data and two mandatory status bytes.

With reference to the physical (electrical) layer (606), variousadditional components of the DTC are depicted including a dynamicmagnetic stripe module (620), a display driver (622) and a correspondingdisplay screen (624), a battery (626) and a crystal (628) that providesan oscillator that is used to determine the clock signal for all of theelectronic devices on the DTC.

Also depicted in FIG. 6A is a diagrammatic representation of the rearside of a DTC (630) including a dynamic magnetic stripe (632).

Additional elements are also depicted in the physical (electrical) layer(606) including an EMV device antenna (634), an NFC antenna (636)connected to the communications module (610) and a Bluetooth antenna(638) also connected to the communication module (610).

With reference to FIG. 6B, the same abstract layers as depicted in FIG.6A are illustrated in FIG. 6B although the embodiment illustrated inFIG. 6B is an embodiment including DTC scroll/enter keys (640) that auser operates to effect functions including changes to the DTCpersonality. In a preferred embodiment, the DTC scroll/enter keys (640)includes touch sensitive buttons that may be activated by simplytouching a button or pad on the DTC and maybe used to scroll throughvarious options including available DTC personalities, and may also beused to power the DTC on or off.

With reference to FIG. 6C, an enlarged version of the Physical(Electrical) Layer (606) of FIGS. 6A and 6B is detailed for the purposeof more clearly illustrating the individual elements of the Physical(Electrical) Layer.

FIG. 7A details the data flow between devices as a result of theissuance of a command from a user's mobile device and receipt of datafrom the DTC to the user's mobile device. In particular, FIG. 7Aprovides a diagrammatic representation of a DTC according to anembodiment of the invention and is effectively a repetition of thediagrammatic representation of FIG. 7C with the addition of a mobiledevice (700). Overlaid on the diagrammatic representation is a series ofarrowed line segments depicting the flow of data as it occurs to, andfrom, the mobile device (800) and individual elements contained withinthe DTC as depicted in FIG. 7C.

With reference to FIG. 7A, in the instance of a user issuing a commandfrom their mobile device (700) to the DTC, the command and/or dataassociated with same, is communicated along data flow 702 and in theexample depicted in FIG. 7A, is communicated wirelessly to the DTCeither by NFC or Bluetooth wireless capability. The DTC receives thecommand issued by the mobile device (700) and indicated by the data flow(702) and receives the command and/or data as depicted by data flow(704) at the communications module (706). The communications module(706) having converted the command and/or data received (704), passes asignal to the MCU (708) along data flow path (710) for processing by theMCU (708).

In the event that the data received by the MCU (708) depicted by dataflow (710) represents a command requiring the MCU (708) to communicatewith the EMV device (712), then the MCU (708) transmits a signal to thearbitration device (714) depicted by data flow (716) to activate thearbitration device (714) to isolate the normal connection between theEMV device contacts and the EMV device (712). Further, in addition toisolating the normal communication between the EMV device contacts andthe EMV device (712), the arbitration device (714) activates connectionbetween the MCU (708) and the EMV device (712).

Once the arbitration device (714) has been activated to enablecommunication between the MCU (708) and the EMV device (712), the MCU(708) transfers data as depicted by data flow (718) to the EMV device(712). In the instance of the command issued by the mobile device (700)to effect a change in personality of the DTC, the EMV device (712) uponreceiving and altering the EMV device (712) personality, in accordancewith data provided as depicted by data flow (718), the EMV device (612)provides a return signal as depicted by data flow (720) to the MCU (708)confirming that the change in personality of the EMV device (712) hasbeen effected. Once required communication between the EMV device (712)and the MCU (708) has been completed, the arbitration device (714) mayrestore communication between the EMV device (712) and the EMV devicecontacts.

At this point in time, the MCU (708) transmits a further signal to thearbitration device (714) to restore the normal communication between theEMV device contacts and the EMV device (712) and at the same timeisolating the communication path between the MCU (708) and the EMVdevice (712). This signal is depicted in FIG. 7A as the data flow (722).

At this stage, the MCU (708) generates and transmits a signal to thecommunications module (706) as depicted by data flow (724), said signalbeing a signal confirming the alteration of the EMV device (712)personality according to the instruction initiated at the user's mobiledevice (700). The communications module (706) upon receiving the signal(724) converts the signal for wireless transmission to the mobile device(700), the wireless signal depicted as data flow (726).

The user's mobile device (700) receives the wirelessly transmittedsignal (726) and upon conversion of that wireless signal, the user'smobile device (700) internally processes the signal (726) and provides avisual indication to the user on the user interface of the mobile device(700) confirming the requested change in personality of the EMV device(712) and that the DTC will now operate according to the personality ofthe card requested by the user. FIG. 7A further depicts data flow (728)and (730) from the MCU (708) to each of the dynamic magnetic stripe(732) and display (734) respectively for the purpose of conforming theparameters of the dynamic magnetic stripe with those that define theuser selected personality and to display information relevant to theselected personality such as, for example, a default name for theselected personality (e.g. VISA, MasterCard, AMEX etc.) or a userdefined name for the selected personality (e.g. Personal Account card,Business Account Card etc.).

With reference to FIG. 7B, a data flow is illustrated as for FIG. 7Aalthough, in the embodiment depicted in FIG. 7B, the request to select aparticular DTC personality is effected by operation of the DTCscroll/enter keys (736), the signal from the scroll/enter keys (736) tothe MCU (708) depicted as data flow (738), Of course, as will berecognised by skilled readers, a particular advantage of the embodimentdepicted in FIG. 7B, wherein the DTC comprises DTC scroll/enter keys(736) to effect a change in DTC personality, it is not necessary to havea smart phone (700) in close proximity nor wireless communicationcapabilities such as NFC or Bluetooth on either the smart phone (700) orthe DTC.

With reference to FIGS. 8A to 8F, various embodiments are described foreffecting operable communication between an EMV device (800) and a MCU(802) and an EMV device (800). In particular, FIGS. 8A to 8F inclusiveprovide additional detail, as compared with previous figures, regardingthe connections between an external contact plate (804) that is providedto effect communication between transaction devices (such as EPTPOSterminals and ATM machines) and the EMV device (800) and theconnection(s) between the external contact plate (804) and the internalcontact plate (806) that is presently included in most, if not all,digital transaction cards that include an EMV device.

In this regard, the provision of an external contact plate (804) and aninternal contact plate (806) is an artefact of the manufacturing processfor digital transaction cards that include an EMV device (800). Inembodiments of the present invention that include both an externalcontact plate (804) and an internal contact plate (806), the opportunityexists to route electrical connections between the external contactplate (804) and the internal contact plate (806) in an arrangement otherthan a direct one to one connection between corresponding electrodes ofthe external contact plate (804) and the internal contact plate (806).

With specific reference to FIG. 8A, an embodiment is diagrammaticallydepicted in which the electrical connections accessible to digitaltransaction devices by way of the external contact plate (804) areconnected to an arbitration device (807) and depending upon the state ofthe arbitration device (807), individual electrodes of the externalcontact plate (804) may be electrically connected by the arbitrationdevice (807) to their counterpart electrodes of the internal contactplate (806).

In order to provide a direct connection between counterpart electrodesof the external contact plates (804) and the internal contact plates(806), the arbitration device (807) operates to connect electrodesidentified as GND (808), Vcc (810), RST (812), CLK (814), I/O (816) andthe blank terminal (818) such that all are connected respectively totheir counterpart connection of the internal contact plate (806) suchthat the aforementioned electrodes of the external contact plates (804)would be connected respectively to GND (820), Vcc (822), RST (824), CLK(826), I/O (828) and blank terminal (830).

Accordingly, when in an appropriate state, the arbitration device (807)would operate to connect the individual electrodes of the externalcontact plate (804) directly to their counterpart terminal of theinternal contact plate (806) which in turn are connected to theappropriate connection points of the EMV device (800) to enable the EMVDevice (800) to operate with digital transaction devices. In thisconfiguration, the EMV device (800) would operate normally with digitaltransaction devices interfacing with individual electrodes of theexternal contact plate (804) and any electrical signals applied to anyone of the external contact plate (804) electrodes, namely, GND (808),Vcc (810), RST (812), CLK (814), I/O (816) and blank terminal (818)would pass through the external contact plate (804) electrode throughthe arbitration device (807) and pass directly to the counterpartelectrode of the internal contact plate (806) namely, GND (820), Vcc(822), RST (824), CLK (826), I/O (828) and blank terminal (830).

However, in instances where communication between an MCU (802) and theEMV device (800) is required, the arbitration device (807) adopts analternative state and connects the data and control signal lines of theMCU (802) through the arbitration device (807) to the individualelectrodes of the internal contact plate (806) which in turn areconnected to the appropriate I/O and control lines of the EMV device(800). Accordingly, the arbitration device (807) in the embodimentgraphically represented in FIG. 8A acts as a collection of single poledouble throw switches to either connect the MCU (802) to the electrodesof the internal contact plate (806) and thus the relevant connectionswith the EMV device (800) or alternatively, when switched to itsalternate mode, the arbitration device (807) disconnects any connectionbetween the MCU (802) and the EMV device (800) and connects the externalcontact plate (804) electrodes to the counterpart electrodes of theinternal contact plates (806) which in turn are connected to theappropriate connections of the EMV device (800).

Operationally, when implementing the embodiment depicted in FIG. 8A, anycommunication between the MCU (802) and the EMV device (800) would needto occur at a time that the user of the digital transaction card did notrequire, or attempt, a transaction with a digital transaction devicesuch that signals were applied to the electrodes of the external contactplate (804). Of course, in the event that a digital transaction waseither prevented, or terminated, as a result of the arbitration device(807) switching to an alternate state such that connection between theexternal contact plate (804) electrodes and the relevant connectionpoints of the EMV device (800) were no longer present, the digitaltransaction would likely terminate and would fail to execute. Whilstsuch an outcome may be acceptable to a financial institution with whichthe user was attempting to conduct a digital transaction, it is unlikelythat users would consider such an interruption acceptable and it ispreferable that the arbitration device (807) were unable to interruptcommunications with a digital transaction device that is communicatingwith the EMV device (800). Further, any potential interruption to dataflow in the “transaction path” of devices can lead to a requirement forthe device, or component, to require re-certification. As previouslydescribed, the process of re-certification of a component for operationin an electronic digital transaction network can be time consuming andexpensive and is preferably avoided.

With reference to FIG. 8B, an alternative to the embodiment depicted inFIG. 8B is diagrammatically represented in which the arbitration device(807) solely controls the connection of the MCU (802) with relevantelectrodes of the internal contact plates (806) and thus relevant signalconnection points of the EMV device (800). In this particularembodiment, the external contact plate (804) electrodes remain directlyconnected to their counterpart electrodes of the internal contact plate(806) at all times and remain connected irrespective of the state of thearbitration device (807). In this particular embodiment, the arbitrationdevice (807) acts as a series of single pole single throw switches sinceit is only operable to connect single lines from the MCU (802) toelectrodes of the internal contact plate (806) and thus signalconnection points of the EMV device (800). Of course, in the instance ofthe embodiment of FIG. 8B, it is necessary to consider the possibilityof electrical signals being applied to the electrodes of the externalcontact plate (804) during periods in which the arbitration device (807)has connected the MCU (802) to the EMV device (800). It will beunderstood by skilled readers that it is possible to employ varioushardware configurations to ensure that electrical signals that couldpotentially damage a device are prevented from reaching the device. Inan embodiment, appropriate hardware elements are employed to divertinappropriate signal energy applied to electrodes of the externalcontact plate such that they are prevented from transmission to the EMVdevice (800) and the arbitration device (807) or the MCU (802). Anadditional issue to consider is the potential for communications betweenthe MCU (802) and the EMV device (800) to be monitored, and/orinterfered with, as a result of connecting a device to the externalcontrol plate (804) and in this instance, it is expected thatembodiments configured in accordance with the arrangement depicted inFIG. 8A would encrypt (832) any communications between the MCU (802) andthe EMV device (800) to thwart any attempt to monitor, or interferewith, such communications by accessing the signals passing between theMCU (802) and the EMV device (900) from the external contact plate (804)electrodes.

With reference to FIG. 8C, an alternative arrangement is depictedregarding electrical connection of the MCU (802) and the EMV device(800) wherein the arbitration device (807) connects and/or disconnectsselective electrodes of the external contact plate (804) with theinternal contact plate (806). As depicted in FIG. 8C, the electrodes GND(808), and RST (812) are connected to the arbitration device (807) andthe arbitration device (807) is operable to connect those electrodes ofthe external contact plate (804) with their counterpart electrodes inthe internal contact plate (806), namely, GND (820) and RST (824).Accordingly, the electrodes that are not connected to the arbitrationdevice (807) of the external contact plate (804) include electrodes Vcc(810), CLK (812) and I/O (816). These particular electrodes are directlyconnected to their counterpart electrodes in the internal contact plates(806), namely, Vcc (822), CLK (826) and I/O (828) and remain connectedat all times.

Similarly, in the embodiment of FIG. 8C, only selected electricalconnection points of the MCU (902) are connected to the arbitrationdevice (807) for switchable connection to electrodes of the internalcontact plate (806). According to the embodiment depicted in FIG. 80,the MCU (802) has permanent connections with various electrodes of theexternal contact plate (904), namely GND (808), Vcc (810, 822) and CLK(814, 826). Similarly, the I/O electrode of the external contact plate(804) and the internal contact plate (806) are permanently connected toeach other and the serial I/O communication connection point of the MCU(802). The embodiment depicted in FIG. 8C has the advantage of reducingattempts to monitor communications between the MCU (802) and the EMVdevice (800) by accessing electrodes of the external contact plate (804)but suffers the disadvantage that some parts of the transaction flow areinterrupted by a switchable device, namely, the arbitration device (807)and hence, re-certification of the device embodied in the DTC may berequired,

With reference to FIG. 8D, a further alternative embodiment is depictedwherein the embodiment includes an external Vcc detection circuit (838)which acts to detect the presence of electrical power connected toexternal contact plate electrode Vcc (810) which would indicate theconnection of the external contact plate with a digital transactiondevice for the purpose of conducting a digital transaction. In thisembodiment, the external contact plate electrode Vcc (810) is connectedto the MCU (802) through an external Vcc detection circuit such that theMCU (802) can receive a signal confirming that electrical power has beenapplied to external contact plate electrode (810) thus indicating theinsertion of the digital transaction card into a digital transactiondevice (e.g. an EFTPOS terminal or an ATM). In this embodiment, selectedelectrodes of the external contact plate, namely, the GND (808)electrode and the RST (812) electrode are connected to independentswitchable devices (834 and 836) which can connect those electrodes toeither the MCU (802) or their counterpart electrodes in the internalcontact plate, namely, GND (820) electrode and RST (824) electroderespectively. This embodiment has the advantage of providing MCU (802)with a signal from the external Vcc detection circuit (838) indicatingthat the user has elected to conduct a digital transaction and hence,the MCU (802) can cease its communication with the EMV device (800) inorder to allow a digital transaction to be completed by the user andsubsequently resuming communication between MCU (802) and the EMV device(800) upon detection of the absence of electrical power connected to theVcc (810) electrode of the external contact plate (804). It will berecognised by skilled readers that a Vcc Detection Circuit could be usedin any embodiment to provide an indication to the MCU that power hasbeen applied to the Vcc electrode thus indicating insertion of the DTCinto a transaction device.

In yet a further embodiment, FIG. 8E depicts a configuration wherein theexternal contact plate (804) electrodes are directly and permanentlyconnected to their counterpart electrodes of the internal contact plate(806) and at the same time are permanently connected to appropriatesignal lines of the MCU (802) and the EMV device (800). In thisparticular configuration, the electrodes of the external control plate(804) and internal contact plate (806) are permanently connected withboth the MCU (802) and the EMV device (800) thereby requiring anycommunication between the MCU (802) and EMV device (800) to be encrypted(832) to thwart any attempt to monitor, or interfere with,communications between the two device by accessing the electrodes of theexternal contact plate (804). Whilst this particular embodiment has thedisadvantage of requiring encryption of all communications between theMCU (802) and the EMV device (800), it does embody the advantage ofavoiding any interruption to the existing transaction flow that wouldoccur with a EMV device (800) when taking part in a digital transactionand hence should avoid any need to re-certify the EMV device whenincorporated in a Digital Transaction Card with communication effectedbetween the MCU (802) and the EMV device (800) according to theembodiment depicted in FIG. 8E.

With reference to FIG. 8F, a further alternative embodiment foreffecting communication between an MCU (802) and EMV device (800) isdepicted. In this particular embodiment, the individual electrodes ofthe external contact plate (804) are directly and permanently connectedto their counterpart electrodes of the internal contact plate (806)which in turn are permanently connected to the relevant electricalconnection points of the EMV device (800). However, in order to effectcommunication between the MCU (802) and the EMV device (800), eachdevice is provided with its own antenna, namely, EMV device antenna(839) and MCU controller antenna (840). In the embodiment of FIG. 8F,both the EMV device (800) and the MCU (802) have their own RFcommunications circuitry incorporated into the respective device suchthat each device can communicate wirelessly. In an embodiment, the EMVdevice (800) and the MCU (802) are equipped with RF communicationcircuitry that can be electrically attached to an antenna and cancommunicate in accordance with the NFC communications protocol. In thisinstance, the EMV device (800) and MCU (802) effectively communicatewith each other by NFC communications conducted on the digitaltransaction card.

Of course, in the embodiment of FIG. 8F, it is necessary to encrypt(832) any communication between the EMV device (800) and the MCU (802)in order to avoid external third parties monitoring those communicationsby use of an NFC receiving device but as for various of theaforementioned embodiments, the embodiment of FIG. 8F has the advantagethat there is no potential interruption to the transaction flow thatwould usually occur between an external contact plate and an EMV device.Hence, re-certification would likely be avoided with such an embodimentfor effecting communications between an EMV device (800) and an MCU(802) incorporated in a Digital Transaction Card.

When seeking to develop a Digital Transaction Card that is operable withan existing digital transaction network infrastructure, it is preferablethat the Digital Transaction Card is operable to communicate withdevices already present within an existing network infrastructureaccording to the communication capabilities and protocols recognised andestablished for devices in that network. In this regard, merchantterminals, and other devices such as Automatic Teller Machines, thatpresently exist in established digital transaction networks providecommunication facilities between credit cards and devices according tothe standards developed for Near Field Communications, physical contactwith the EMV device contacts of a credit card and by swiping and readingthe magnetic stripe on the rear face of a credit card. Accordingly, whenseeking to provide a Digital Transaction Card operable with an existingtransaction network yet including additional functionality, it ispreferable to provide a Digital Transaction Card that is operable withan existing digital transaction network according to the currentprotocol standards and interfaces. As a result, it is preferred toprovide a DTC that also has the capability to be used with a merchantterminal that relies upon the use of the magnetic stripe and as aresult, in an embodiment of the invention, the DTC is provided with adynamic magnetic stripe that is controlled by the magnetic stripecomponent (732) as depicted in FIG. 7A and 7B.

In this regard, since the DTC according to an embodiment of theinvention is operable to adopt any one of a number of personalities thatmay be selected and activated by a user, the magnetic stripe on the rearface of the Digital Transaction Card requires a magnetic stripe that maybe configured according to the personality of the Digital TransactionCard at any particular point in time. Accordingly, the MCU (802) isprovided with a data connection with the magnetic stripe component (732)as depicted in FIG. 7A and 7B and is operable to configure the magneticstripe on the rear face of the Digital Transaction Card such that itaccords with the magnetic stripe relevant to the personality of theDigital Transaction Card at any particular point in time.

Further, since the Digital Transaction Card according to the embodimentof the invention depicted in the Figures may include a display, the MCU(802) is provided with direct connection with the display module (734)as depicted in FIG. 7A and 7B which drives the display (734) that can beused to provide information to a user of the Digital Transaction Cardindependently of the user's mobile device (700).

A Digital Transaction Card according to an embodiment of the inventionprovides a user with the ability to combine various Digital TransactionCards onto a single card with the ability to select and activate any oneof the various personalities that are stored on the card at anyparticular point in time for the purpose of effecting a transaction.Further, according to the embodiments depicted herein, the DigitalTransaction Card is operable according to all of the available protocolsand interfaces that presently exist in established digital transactionnetworks and therefore, a Digital Transaction Card according to anembodiment described in the present specification can be used withexisting digital transaction networks anywhere in the world. This isparticularly important for countries in which the installed digitaltransaction network includes devices that have yet to be upgraded tocommunicate with Digital Transaction Cards according to NFC capabilitiesand may be restricted to either direct physical contact with the EMVdevice contact plate or use of the magnetic stripe which may beprevalent in countries that are considered to fall within the categoryof “developing nations.” Further, even in “developed nations” whereinthe existing digital transaction network infrastructure includes manyterminals that have NFC communication capabilities, many consumers havenot yet elected to adopt the E-Wallet services offered by manycommercial operators since their mobile phone or smartphone device doesnot have NFC communication capabilities. In order to use the presentlyoffered E-Wallet commercial services, it is necessary to implement thoseservices on a smartphone that includes NFC communication facilities. Ofcourse, a Digital Transaction Card according to an embodiment describedin the present specification may communicate with any device thatincorporates a Bluetooth communications facility which includes manyolder generation smartphones and hence, according to an embodiment ofthe invention, a user may select and activate a particular personalityfor a Digital Transaction Card by selecting and activating thatpersonality on their smartphone equipped solely with Bluetoothcommunication facilities and communicate that instruction to a DigitalTransaction Card according to established Bluetooth communicationprotocols. Having selected and activated a particular personality fortheir Digital Transaction Card using Bluetooth communication facilities,the Digital Transaction Card may be used to effect a transaction with anexisting digital transaction network according to any of the currentlyavailable protocols and interfaces including magnetic stripe andphysical contact with the EMV device contact plate.

TABLE 1 is a chart of the aforementioned DTC embodiments (414, 416, 418and 422) depicted in FIG. 4D when the EMV device associated with the DTCis software-enhanced detailing the combination of features in eachembodiment. It will be understood that this listing of embodimentsrepresents only a selection of possible embodiments and does notrepresent an exhaustive list of all possible embodiments. In the TABLE 1below, the tick ✓ symbol signifies that a feature is present, and thecross x symbol signifies that a feature is not present.

TABLE 1 Software-Enhanced (Java EMV with applet) EMV Device havingModified MCU with Scroll/ Contactless MCU with NFC Bluetooth EnterEmbodiment Comms Capability MCU Comms Capability Comms CapabilityBattery Card Display Keys 414 ✓ x x x x x x 416 x ✓ ✓ x ✓ x x 418 x ✓ ✓✓ ✓ ✓ x 4/8 Active Matrix 422 x ✓ ✓ ✓ ✓ ✓ ✓ 4/8 Active Matrix

In the first embodiment in TABLE 1, the DTC (414) requires the use of aData Assistance Device (DAD) with a modified NFC capability such as asmartphone to communicate data and commands to an applet associated withthe EMV device that can establish a secure session between theNFC-enabled DAD and the DTC via a contactless interface. In this regard,the DAD requires an application that establishes a secure session withthe DTC. Data sent via the secure session includes APDU packetscontaining commands, for example Global Platform Commands, or APDUpackets containing commands that authorize a management applet on theEMV device to send Global Platform Commands to applets containing cardpersonalities. The commands sent to the management applet may include asequence of commands to install a new personality or to change anoperational parameter or status of an existing personality. DTC (414)further requires software encryption to isolate the EMV external contactplate, as described above with reference to FIGS. 8A to 8F. The DTC(414) is limited to use with an NFC-enabled phone, but has the advantageof low cost and low propensity to fail since the DTC does not include anMCU, display or scroll/enter keys.

DTC (416) also requires the use of a Data Assistance Device (DAD), suchas a smartphone, to communicate data and commands to an appletassociated with the EMV device that can establish a secure sessionbetween the NFC-enabled DAD and the DTC via a contactless interface. Thedifference between DTCs (414) and (416) is that DTC (416) includes anMCU that can accept wireless communication (e.g. NFC), and can accept asecure session between the DAD and the DTC containing the MCU. Theapplication on the DAD creates a secure session with the MCU within theDTC and data sent via the secure session includes APDU packetscontaining commands, for example Global Platform Commands, where the MCUforwards the commands to the EMV applet. DTC (416) may further includesoftware encryption to isolate the EMV external contact plate, but alsoallows hardware encryption involving physical isolation of the EMVcontact plate as described above with reference to FIGS. 8A to 8F. Theadvantages of using DTC (416) include low to medium cost and lowpropensity to fail, and includes an MCU that can assist data transferwith a DAD.

DTC (418) also requires the use of a Data Assistance Device (DAD), suchas a smartphone, to communicate data and commands to an appletassociated with the EMV device that can establish a secure sessionbetween an NFC or Bluetooth enabled DAD and the DTC via a contactlessinterface. DTC (418) includes an MCU that can accept wirelesscommunication (e.g. Bluetooth and NFC), and can accept a secure sessionbetween the DAD and the DTC containing the MCU. The application on theDAD creates a secure session to the MCU within the DTC and data sent viathe secure session includes APDU packets containing commands, forexample Global Platform Commands, where the MCU forwards the commands tothe EMV applet. In addition, DTC (518) is configured to accept commandsthat authorize the MCU to send APDU packets containing commands, forexample Global Platform Commands, to amend parameters pertaining to apersonality. DTC (518) may further include software encryption toisolate the EMV external contact plate, or hardware encryption involvingphysical isolation of the EMV contact plate as described above withreference to FIGS. 8A-8F. The advantages of using DTC (418) includemedium cost, medium propensity to fail, and is not limited to use withan NFC-enabled DAD, but in view of DTC (418) including an MCU anddisplay (420) there is a higher cost associated with production of DTC(518) as compared with DTC (414) and (416).

When using DTC (422), the skilled addressee will understand that the useof a DAD such as a smartphone is not necessarily required, but may beused, to change the personality of the card. In any event, the DAD isnecessary to initially set up the card and download/store multiplepersonalities, but subsequent to the initial setup, the card itself maybe used to change the operational parameters of a card's personalityusing the scroll/enter keys (426). The DTC (422) contains an applet, andan MCU that can accept wireless communication (e.g. Bluetooth or NFC), asecure session between the DAD and the DTC containing the MCU (i.e.during the initial setup), and a secure session between the MCU and theEMV for subsequent amendments to the parameters of a personalityinvolving transfer of data between the MCU and EMV (applet or managementapplet). The MCU is programmed to accept commands from a localinterface, which may for example include the scroll/enter keys (426),and convert the keystrokes into commands. The application on the DADcreates a secure session with the MCU within the DTC during the initialsetup of the DTC (422) and data sent via the secure session includesAPDU packets containing commands, for example Global Platform Commands,where the MCU is authorised to forward the commands onto the EMV applet.In an alternative embodiment, data that is sent via the secure sessionwill consist of commands that authorize the MCU to send APDU packetscontaining commands to a management applet on the EMV device. TheManagement applet then sends commands (for example global platformcommands) to effect an amendment to an operational parameters or statusto the appropriate applet. When the scroll/enter keys (426) are used tochange the personality of the DTC (422), transmission is authorized bythe local interface that authorizes the MCU to send APDU packetscontaining authorization commands to either the Management app or GlobalPlatform Commands to the applet containing the card personalitypersonalities. DTC (422) may further include software encryption toisolate the EMV external contact plate, or hardware encryption involvingphysical isolation of the EMV contact plate as described above withreference to FIGS. 9A-9F.

DTC (422) has the advantage of locally selecting one from many multipleconcurrent personalities stored on the card with no risk of discovery ofcard details during updates or changes (i.e. changes to status/updates)since card details are not transmitted. In addition, less time isrequired to effect updates or changes (i.e. changes to status/updates),minimal amounts of data is required to be transferred to effect a changein personality, and the ability to change DTC personalities without theuse of a DAD. However, DTC (422) has a higher production cost and due toits complexity may have a higher propensity to fail.

Table 2 is a chart of the abovementioned DTC embodiments (414, 416, 418and 422) when the EMV device associated with the DTC isfirmware-modified, detailing the combination of features that arepresent in each embodiment. Again, the ✓ symbol signifies that a featureis present, and the x symbol signifies that a feature is not present,and it is to be understood that this listing of embodiments representsonly a selection of possible embodiments that may be configured withdiffering combinations of features and is not intended to represent anexhaustive listing.

TABLE 2 Firmware-Modified EMV Device Multiple Multiple EMV DevicePersonalities Personalities having Modified for Single for Multiple MCUwith Scroll/ Contactless Card Association Card Association MCU with NFCBluetooth Enter Embodiment Comms Capability Scheme Schemes CommsCapability Comms Capability Card Display Keys 414 ✓ ✓ x x x x x 416 x xx ✓ x x x 418 x ✓ ✓ ✓ ✓ ✓ x 4/8 Active Matrix 422 x ✓ ✓ ✓ ✓ ✓ ✓ 4/8Active Matrix

In the first embodiment in TABLE 2, the DTC (414) requires the use of aData Assistance Device (DAD) with a modified NFC capability such as asmartphone to communicate data to an EMV device that isfirmware-modified. As previously described, a firmware-modified EMVdevice has an external DTC CPU that includes firmware that is operableto write data (for example, LDTDP data) to staging memory, such that,when the DTPU is activated, the DTPU copies the data to secure recordmemory (secure element) in the DTPU in a manner that causes the DTC toadopt a particular card personality or assist in conducting a digitaltransaction in some other way. Data relating to each personality may bestored in memory associated with the DAD, wherein communications betweenthe DAD and DTC may be in the form of instructions to download and copythe data into the secure element for the purpose of updating thepersonality of the DTC. The firmware-modified DTC (414) is limited touse with an NFC-enabled DAD and use of an EMV device having modifiedcontactless communications capability in order to securely receive datareceived from the NFC-enabled DAD, but has the advantage of being ableto adopt multiple personalities for a single Card Association Scheme andlow cost and low propensity to fail since the DTC (414) does not includean MCU, display or scroll/enter keys.

The firmware-modified DTC (416) also requires the use of a DataAssistance Device (DAD), such as a smartphone, to communicate data to anEMV device that is firmware-modified as described above. The differencebetween DTCs (414) and (416) is that DTC (416) includes an MCU that canstore data relating to multiple personalities (and/or data that may berelevant to changing some other digital transaction parameter) ratherthan storing same in the DAD memory, and can accept a secure sessionbetween a DAD with wireless connectivity (either NFC or Bluetooth) andthe DTC containing the MCU which also has wireless connectivity (eitherNFC or Bluetooth). The advantages of using the firmware-modified DTC(416) include low cost and low propensity to fail, there being norequirement for an NFC-enabled DAD (in that the MCU can acceptcommunication with a phone that is solely Bluetooth-enabled, forexample), the ability to adopt multiple personalities for a single CardAssociation Scheme, and the presence of an MCU that can assist securedata transfer from the DAD and does not require the use of an EMV devicehaving modified contactless communications capability.

DTC (418) in TABLE 2 also requires the use of a Data Assistance Device(DAD), such as a smartphone, to communicate data to a firmware-modifiedEMV device that can establish a secure session between a DAD withwireless connectivity (NFC and/or Bluetooth) and the DTC via acontactless interface. DTC (418) includes an MCU that can acceptwireless communication from both NFC and Bluetooth-enabled DADs, and canthereby establish a secure session between a majority of phones and theDTC containing the MCU. The advantages of using DTC (418) includelow-to-medium cost, low-to-medium propensity to fail, and there being norequirement to use solely an NFC-enabled DAD, but in view of DTC (418)including an MCU and display (420) there is a higher cost associatedwith production of DTC (418) as compared with DTC (414) and (416).

When using the DTC (422) described in TABLE 2, the skilled addresseewill understand that the use of a DAD such as a smartphone is notnecessarily required, but may be used, to change the personality of thecard or to assist in some other way in conducting a digital transaction.In any event, the DAD is necessary to initially set up the card anddownload/store multiple personalities in the MCU, but subsequent to theinitial setup, the card itself may be used to change the operationalparameters of a card's personality or to assist the digital transactionin some other way using the scroll/enter keys (426). An MCU is used toaccept wireless communication (both Bluetooth and NFC) from the DADduring an initial setup, and is further programmed to accept commandsfrom a local interface, which may for example include the scroll/enterkeys (426), and convert the keystrokes into commands. When thescroll/enter keys (426) are used to change the personality of the DTC(422) or to perform some other task that assists the digitaltransaction, transmission is authorized by the local interface thatauthorizes the MCU to select stored data and copy same to the secureelement.

DTC (422) has the advantage of locally selecting one from many multipleconcurrent personalities stored on the card with no risk of discovery ofcard details during updates or changes (i.e. changes to status/updates)since card details are not transmitted. Further advantages includereduced time to effect updates or changes (i.e. changes tostatus/updates), minimal amounts of data being required to betransferred to effect a change in personality, and the ability to changeDTC personalities without the use of a DAD. However, DTC (422) has ahigher production cost and due to its complexity may have a higherpropensity to fail.

The reference to any prior art in this specification is not, and shouldnot be taken as, an acknowledgement or any suggestion that the prior artforms part of the common general knowledge.

Throughout this specification and claims which follow, unless thecontext requires otherwise, the word “comprise”, and variations such as“comprises” and “comprising”, will be understood to mean the inclusionof a stated integer or step, or group of integers or steps, but not theexclusion of any other integer or step or group of integers or steps.

It will be understood by persons skilled in the relevant field oftechnology that numerous variations and/or modifications may be made tothe invention as detailed in the embodiments without departing from thespirit or scope of the invention as broadly described. The presentembodiments are therefore to be considered in all aspects asillustrative and not restrictive.

1-47. (canceled)
 48. A digital transaction apparatus including: a DataAssistance Device (DAD), including: a user interface that is operable toat least select data, and a DAD transmitter; a Digital Transaction Card(DTC), including: a Digital Transaction Processing Unit (DTPU), and aDTC receiver, wherein the DAD and DTC are operable to transfer data fromthe DAD to the DTC and when subsequently using the DTC to effect adigital transaction, the DTC operates in accordance with the dataselected and transferred from the DAD to the DTC, and wherein thedigital transaction apparatus further includes: a remaining battery lifeestimation system operable to detect an occurrence of at least oneelectrical event and to measure the duration of the at least oneelectrical event, each electrical event having an associated power usageamount, and, subsequent to detection of an occurrence of an at least oneelectrical event, the remaining battery life estimation systemcalculates the total energy usage using the associated power usageamount in respect of the at least one electrical event and the durationof the at least one electrical event.
 49. A digital transactionapparatus according to claim 48, wherein the transferred data includesdata pertaining to one or more selectable personalities.
 50. The digitaltransaction apparatus according to claim 49, wherein data pertaining tothe plurality of selectable personalities is stored on the DAD, andchanging the current personality of the DTC to the selected personalityincludes: receiving, by the DAD and by operation of the DAD userinterface, the instruction to change the current personality of the DTCto the selected personality; transmitting, by the DAD transmitter to theDTC receiver, data related to the selected personality; andimplementing, in the DTC, a change from the current personality to theselected personality in accordance with the data such that when the DTCoperates with a digital transaction device to effect the digitaltransaction, the digital transaction device recognizes the selectedpersonality.
 51. The digital transaction apparatus according to claim49, wherein data related to the plurality of selectable personalities isstored on the DTC, and changing the current personality of the DTC tothe selected personality includes: receiving, by the DAD, and byoperation of the DAD user interface, the instruction to change thecurrent personality of the DTC to the selected personality;transmitting, by the DAD transmitter to the DTC receiver, theinstruction to change the current personality of the DTC to the selectedpersonality; and implementing, in the DTC, a change from the currentpersonality to the selected personality in accordance with theinstruction such that when the DTC operates with a digital transactiondevice to effect the digital transaction, the digital transaction devicerecognizes the selected personality.
 52. The digital transactionapparatus according to claim 48, wherein the selected and transferreddata includes one or more instructions.
 53. The digital transactionapparatus according to claim 52, wherein the one or more instructionsinclude instructions to change a current personality of the DTC to apersonality selected from a plurality of selectable personalities. 54.The digital transaction apparatus according to claim 48, wherein the DTCincludes a user interface.
 55. The digital transaction apparatusaccording to claim 54, wherein the selected data transferred from theDAD to the DTC including data pertaining to the plurality of selectablepersonalities and stored on the DTC are individually selectable byoperation of the DTC user interface.
 56. The digital transactionapparatus according to claim 55, wherein changing a current personalityof the DTC to the selected personality includes: receiving, by operationof the DTC user interface, one or more instructions to change thecurrent personality of the DTC to the selected personality; andimplementing, in the DTC, a change from the current personality to theselected personality in accordance with the one or more instructionssuch that when the DTC operates with a digital transaction device toeffect the digital transaction, the digital transaction devicerecognizes the selected personality.
 57. The digital transactionapparatus according to claim 54, wherein the DTC user interface includesscroll keys and a display, and wherein the DTC scroll keys enable userselection of a personality from the plurality of personalities and thedisplay indicates the selectable personality.
 58. The digitaltransaction apparatus according to claim 48, wherein the DTC includes aDTC external processor for receiving and storing transferred data. 59.The digital transaction apparatus according to claim 48, wherein the DTCincludes a display for displaying information.
 60. The digitaltransaction apparatus according to claim 48, wherein the DTPU is an EMVdevice including a software module having instruction code which, whenexecuted, causes the EMV device to receive and execute commandsaccording to the Global Platform Standard Command set including commandsto install an Applet displaying a credit card personality.
 61. Thedigital transaction apparatus according to claim 48, wherein the DTPU isan EMV device operating in accordance with firmware wherein the firmwarehas been modified to enable the EMV device to receive and execute anexpanded set of commands that, when executed, allows the writing of datato a secure memory element of the EMV device.
 62. The digitaltransaction apparatus according to claim 61, wherein a digitaltransaction device interfaces with the EMV device by physical connectionwith contact terminals of the EMV device, or by contactless connection(ISO 14443 Standard), or by interaction between a magnetic stripe readerassociated with the digital transaction device and a magnetic stripe ofthe DTC.
 63. The digital transaction apparatus according to claim 62,wherein the DTC is a wearable device including a watch, a wrist band, aring or an item of jewelry.
 64. The digital transaction apparatusaccording to claim 62, wherein the digital transaction device is any oneor more of a POS/EFTPOS terminal, an ATM, an internet connected computeror a personal computer.
 64. A Digital Transaction Card (DTC) including:a Digital Transaction Processing Unit (DTPU); and a DTC receiver that isoperable to receive user-selected data from a transmitter associatedwith a Data Assistance Device (DAD), wherein the user-selected data thatis received causes the DTC to operate in accordance with theuser-selected data when the DTC is subsequently used to effect a digitaltransaction, and wherein the DAD and/or the DTC further includes: aremaining battery life estimation system operable to detect anoccurrence of at least one electrical event and to measure the durationof the at least one electrical event, each electrical event having anassociated power usage amount, and subsequent to detection of anoccurrence of an at least one electrical event, the remaining batterylife estimation system calculates the total energy usage using theassociated power usage amount in respect of the at least one electricalevent and the duration of the at least one electrical event.
 65. Aremaining battery life estimation apparatus operable to detect anoccurrence of at least one electrical event and to measure the durationof the at least one electrical event, each electrical event having anassociated power usage amount, and subsequent to detection of anoccurrence of an at least one electrical event, the remaining batterylife estimation apparatus calculates the total energy usage using theassociated power usage amount in respect of the at least one electricalevent and the duration of the at least one electrical event.
 66. Aremaining battery life estimation apparatus operable to detect anoccurrence of at least one electrical event, each electrical eventhaving an associated energy usage amount, and subsequent to detection ofan occurrence of an at least one electrical event, the remaining batterylife estimation apparatus calculates the total energy usage using theassociated energy usage amount in respect of the at least one electricalevent.